Projekt Digital

Der Blog für digitale Business Leader

How to successfully approach an Oracle Forms to APEX migration project

What customers are facing, if they want to move their application from Oracle Forms to APEX.

As migration experts and having completed a number of Oracle Forms to APEX migration projects, we know what it takes to make your project a successful one. In this article we share with you valuable aspects for a successful migration.

It’s about project planning & costing, designing the application architecture, dealing with cross-functionalities, identifying the requirements for an application, a guided team effort with go-to-coach, how to incorporate APEX new features & best practices, designing new interfaces and streamlining the actual implementation. We hope this will help you in your migration project. Good luck!

How to calculate the project?

Before even starting with a migration of Oracle Forms to APEX each stakeholder wants to know the most important values for the project: How long will the migration take, how much budget should be reserved, what are the risks along the way?
Due to the fact that we cover an implementation project with less cost factors for hard and software, the costs of a migration project is directly related to the implementation effort.
To avoid answering this question in the very first beginning, very often the customers start with a fresh implementation of new functionalities beside the existing Forms Application. Usually this is a very good starting point to get familiar with the APEX framework and the way of developing, deploying and testing applications written in APEX in a complete development team.
The team learned to estimate the effort for development and get an impression of the possible obstacles of the APEX framework.

Unfortunately this doesn’t lift the team into a state that they are able to really calculate the complete effort of a migration of an entire forms application.
Why? The development of new functionalities differ at least in two major facts to the work inside a migration project. On the one hand the requirements are given by a business description or very often due to “own ideas” of the development team and not by an existing implementation. On the other hand the new development cover, perhaps distributed over a couple of sprints, a relatively small amount of effort compared to the entire application which increases the amount of work usually by a high factor. Small parts of insecure ends up very probably in hundreds of additional days.

With PITSS Forms Replacer Kit you could calculate the effort of a migration project in great detail. You could decide, which objects should be covered manually after the migration, calculate those complexity by various values, and take the velocity of your team into consideration. All obstacles are identified by the very first moment. With this you reduce risk and gain predictability.

How to architect the application?

With the first page of APEX you create, the question is, how to architect your application. How many APEX apps will you create, what kind of common components are necessary, should plugins be part of the application, what will be covered by Javascript and where should those libraries be placed, and many, many more questions should be answered before your start with the first APEX wizard.

There are multiple facts, which influence the architectural decision.

  • Do you act as an ISV or develop an inhouse application?
  • How many installations of your app will later exist?
  • Which kind of customization is needed?
  • How many developers with which kind of skills will be involved?
  • How often would you like to deploy a new release?

But in a migration there is one big thing, which heavily influences the APEX architecture – that is the existing application. No matter, an APEX application will never ever have the same architectural design like an existing Forms application. But the Forms application define and which way the users are able to navigate through the entire application. All navigation paths, from the Menu, from inside the application, with the various forms builtins could be used to draw a very big landscape of the entire forms application. This will easily visualise part of the application which are bound very closely together.These are perfect candidates for a future part of an APEX application.
Due to the fact that we usually advise a staged approach for a migration, this clustering allow you to migrate the Forms application step-by-step into APEX and have a minimal impact for the business processes.

How to design cross functionalities?

Very often in legacy Forms applications so-called cross-functionalities are designed by the developers on their own. Forms didn’t provide such functionalities in the past. Cross functionalities covers things like I18N, Security, Customisation, logging, authentication, authorisation, UI manipulation, screen resolution, responsive design, Master-Detail-Relationship, and many more.
It doesn’t make sense to overtake this implementation into a new framework which better covers these requirements with its own solutions.
In the analysis phase we identify self implemented cross functionalities inside your Oracle Forms application and we advise Best practice solutions inside the APEX eco-system.
Beside the fact that we are then able to transform this implementation into APEX Best practices, we could with the help of pattern matching identify where you violate your own rules in specific areas of your application. This information helps us to discuss if it’s really necessary to make an exception in that specific part of your application or if it’s just a failure in following your own coding conventions.

How to identify the requirements for the application?

Requirement specifications in migration projects are a big issue! Please read our Blog https://pitss.com/de/requirement_migration for more detailed information. In general more than ⅔ of the existing requirements should be covered by the new solution – even faster, with a smarter UX, more flexible, etc.
How would you like to get aware of this specification? Typically there is no actual and valid requirement specification for the overall application and interviews with the key users for existing functionalities are time consuming, frustrating and failure effective.
There are only two facts you could really trust: On one hand the existing implementation and on the other hand the way the users use your application today. Both of them define how your business is running.
With algorithms from process mining and machine learning we help to cover and recreate the business specifications out of these two facts! This unique approach is awarded by the German government! At the end of this “recording” you get the actual and best requirement specification for your new application.

The advantages are:

  • Faster than code reading
  • More complete than interviews
  • More actual than existing documentation
  • More reusable than all of them above.

How to define releases?

If you take a look at the investment you did in the past for your existing Forms application, it’s obvious that a migration or redevelopment of this application will take its time. Rather than having a big bang in the end, you should proceed like you suppose to do in agile software development. Deploy new releases as kind of “minimum valuable product” as soon as possible. In coexistence with Oracle Forms the APEX application will grow in a way which was once described by Gartner as a staged approach.
Even if you could not break all dependencies in Oracle Forms, you should try to minimize the situation, that a user needs to switch in the user interface between Forms and APEX back and forth to fulfill one business process. No doubt, it’s possible to run Forms and APEX in parallel and allow users to take over context information from one part to another – but it’s against good UX.

The amount of an APEX release of your application should be big enough to cover a couple of variants of a business process, but small enough to not interfere with the complete Forms application. In addition, if you extend the APEX application within this migration with new features or fix bugs, you should be able to deactivate the old functionality in Forms to not get forced to treat data inconsistencies.

Cutting your existing Forms Application into appropriate APEX releases is not as easy. As a quick rule of thumb one APEX application for one Forms Module is too small, more than 30 are too much.
A clear understanding of the dependencies inside Forms and the usage of the existing application from the viewpoint of the business processes helps to identify helpful borders. With recreating a big landscape fromout the code and the possibility to create a process map out of the usage of the Forms application, we could re-architect the Application in a Design Sprint very fast and accurately.

How to train the developers?

APEX is the Low-Code development platform and allows the creation of applications very fast with less code compared to other web technologies like Java or Javascript.
Nevertheless it’s necessary to get familiar with all the concepts, wizards, and possibilities of APEX. Starting with a new application as a functional extension of the existing Forms application is a good idea, because you could learn in a small, dedicated scope all necessary steps from design over implementation until deployment and maintenance of an APEX app. All this without influencing the business in a stressful situation.
In this phase you could make your mind for design guidelines, coding conventions, cross functionality, etc. This is more like a blueprint for your upcoming migration.

If time is ready for starting the migration, the remaining effort is on various levels of complexity. Some of the modules are more lightweight and have some easy replacements in APEX others are more complicated and need more experienced developers.
It’s good practise to allow junior developers to start with the easier modules and tasks, to increase their experience. Sprint by sprint they getting more familiar with the tasks which increae the overall velocity of the team and allow them to pick up more complicated tasks in the next sprint.

How to use a go-to-coach?

If you start with a greenfield approach especially when you are using a new kind of framework, your team will grow more or less at the same speed as the application will grow. The more features your application will get, the more complicated the architecture will be the more knowledge the team will get to cover this. Application and the development team will go side by side. If the team is not aware of reusability, the application won’t benefit from this. But the team will find other solutions, so that a misfit is not obvious from the first view.
This is totally different in migration projects, because the existing legacy application will face the team with all possible issues from the very beginning. From the simple validation of an item to the question of how to architect a huge application – every topic will be irrevocably thrown to the task board of the team. This is overwhelming and stunning to the team. How to start? Where to go? How to coordinate all of this.
That’s the reason to rely on a go-to-coach, which helps the team to once more, grow with the application and trust in following the right path. In the first sprint, where a team usually try to get comfortable with new technologies, learning patterns, allowing the application to move into the one or the other direction because not all requirements are defined, the go-to-coach have the big picture of the legacy application in mind and guide the development on their way in their velocity.

How to benefit from APEX new features?

APEX provides various advantages, which will directly improve the overall experience of your application. For a more detailed description see Oracles Page:
https://apex.oracle.com/en/solutions/oracle-forms/

The most challenging part of the migration is finding the balance between the enthusiasm of using all new fancy features and the boring, repetitive task to take over the still needed functionality from the legacy application.
To achieve this, it’s important to see the Forms Application as specification of requirements and not as copy&paste source for each object.
It’s necessary to identify the business processes in the legacy application and identify the fragments of the data model, the PL/SQL logic and validations behind them. If that is done and valid, you could use them as a kind of springboard to allow yourself to focus on the new functionality very soon.
The FormsReplacerKit allow you to identify the business processes in your application, extract all fragments out of them and use these sets as a customizable springboard for a first APEX application, which could then improved with all new functionalities without the fear of missing parts of the business process.

How to ensure APEX best practices?

As in any other programming language, also in the development of APEX applications best practices span from small naming conventions to decisions on architecture and application modelling.
The second part is easier to decide, if you already have a big picture of the entire application. Rather than starting with a small application and getting forced to redefine the architecture from one sprint to the other, it’s appropriate to take a deep breath on the big picture and make up your mind with the entire application drawn on an endless whiteboard. This picture helps to decide how to cut, model and architect the APEX application of the next dozends of sprints.
On the other hand, if you have decided your single portions of naming and coding convention, nothing else rather than code generators are a smooth and easy way to remind every developer to stay within their own defined borders. As a sample, if you decide a naming convention for global page items, it’s easy for the generator part of the FormsReplacerKit, to follow those naming conventions and create all necessary objects in a correct manner.
Once created, there are good opportunities in APEX due to the fact that the framework is based on a repository approach to continuously prove the rules.

How to design new interfaces?

There are tons of articles out there which focus on psychological effects on user interface design. And all of them are worth reading and considering. Long running legacy applications are mostly not designed with these principles in mind. Even if you take over the same kind of objects (Button, Items, tables, etc) the change of the user interface with colors, arrangement, pictures, behaviour, etc could cause the user on one hand to get enthusiasm due to the feeling of brand new software and on the other hand getting anxious to be forced to learn everything from scratch.
That’s the reason why it’s so important to focus on designing a good user experience in the new application. With APEX you’ll get a big bunch of more functionalities than you have right now with the existing Forms framework to achieve this. Nevertheless consistency is one of the key concepts you should follow.
During the design phase it’s worth discussing the new principles with the potential users. For this a picture is worth more than 1000 words and ease the communication of hows and whys. Usually this can be supported by sketching tools, like Balsamiq (https://balsamiq.com/) These tools speed the design process and allow interactive discussions with the users on the new interface.
To ease the process and don’t get forced to start on a blank page, FormsReplacerKit provides all necessary components for the considered business processes. This helps the designer to not forget any component.

How to streamline the implementation?

If you ask a developer, what they need to get into a flow of software development, you’ll get very often attributes like “no impossible tasks”, “understanding the goal”, “provide all information before start coding”, “provide obstacles before design the solution”, “Focus on the development process”.
A migration project smells different from a fresh software development, because you’re facing a big, complex, eventually not well documented legacy application in the very early stage of your project asked to overtake and improve the supported business processes. That is all other rather than a good starting point to jump into a developer flow.
It’s necessary to identify all obstacles from the existing application, before you start designing the new application. You need to split down the huge migration project into small tasks, which allows a developer to focus on them in an unbreakable manner during the day. And last but not least, you should describe the development process, how the single tasks should be solved, one after the other.
Without any support, this is nearly impossible to achieve. Only to identify the problems during the migration due to incompatibile concepts of Oracle Forms and APEX usually force you to read million LOCs and revisit thousands of objects. And without scripting, you’ll neve know, if you miss something.
Streamline the tasks and describe on Unit/Event/Object-Level exactly, how to redevelop the requirements in APEX is very important, but time consuming, if you manually rewrite the specification from the Oracle Forms Application in conjunction with potential new specification. If you miss, you pay the price, that hundreds of APEX apps and Pages of your application won’t get implemented in the same manner.

The PITSS FormsReplacerKit is designed to parse the entire Forms Application and provide all necessary information about tasks, problems and effort beside a complete recreated requierment specification from the given application. Tasks are split down into managerable items and integrated into the APEX Page designer to allow the developer stepping and staying in their implementation flow.

How to recognise a successful migration project?

Let us put ourselves for a moment into the first day after the migration will be completed and try to see whether the migration was successful or not. How would you know?

  • You don’t forgot a requirement
    Any undocumented specification inside the Oracle Forms Application get recognized and would be overtaken as long as it was still necessary. There was no “Ups” – this works in the past”, during the various rollouts of the new application, even if they were as rare as nobody could even remember them.
  • You stay in time
    According to your origin projekt plan, you could deliver release after release, sprint after sprint the new artefacts as they are designed. You gain trust after the first sprints and the user looking forward to each new functionality.
  • You stay in budget
    There was no need to add additional resources or external vendors to follow your project plan. More than this, the velocity of your development team increase over time and allow more functionality to arrive than you expected.
  • Your team is able to enhance the application faster than before
    After migrating to APEX your team is now able to adjust the application to new business requirements much faster than in the monolithic Forms application. You create a future safe, easy to maintain and enhance architecture, which allows small squads to work efficiently on small pieces of your application.
  • Your business wasn’t blocked at any time
    During the migration Forms and APEX run side by side and provide consistent Business support for the users. As soon as a new functionality was developed inside APEX, the Forms relevant components were deactivated.
  • The user love the new UX
    The users are excited by the new functionality of the APEX application and run their business easier, faster and with more possibilities. From the very beginning, the Users love to see more and more features implemented by the migration team.
  • You was able to integrate new requirements on the fly during the migration
    Due to the fact that you migrate the application from the business process point of view, your team could easily extend the code to fulfill new requirements to this specific part of the application. Every time the team was able to focus on all necessary parts of the application, which belongs to the actual business process.
  • Team and software were able to grow without any unnecessary roundtrips
    From the first day, the architecture of the APEX application was visible for all team members. Each of them know their requirements for the individual learning curve and like a simple puzzle, they could add piece by piece to the APEX application without struggling or redefining it. If new unknown requirements arrived from the business, the architecture was safe and flexible to react with new APEX componentes.

How to treat psychological effects in a migration?

Even if we talk about software and engineering, we should not forget that the migration project will be run by human beings. From our experience, there are two very important points to consider in the early stages of the migration process.

Inevitable identification with the code
Usually it’s the first paradigm of code review, to not personalize the code, but nevertheless there is a lot of emotional binding in between the lines. If a product came along to identify the dependencies and clean technical debt, the first reactions of the developers were: “Shouldn’t I know it better?” and “Sorry, but there is a reason for this”. Doubt and defence are not the best emotions to start a journey into the future.
Sure – there were good reasons in the past, and today is the right time to decide if the reasons still exist. There are many various numbers out trying to argue how many LOCs a developer is able to cover by heart, but however high this number is, it won’t be enough in today’s maintenance situation of Legacy Forms Application.
The deep analysis in the beginning of the migration projects is not to blame the team, the purpose is to bring all of them to the same, highly evaluated and perfect starting point of the project.

Underestimation
In a migration project, three factors coincide that lead to risky processes in the estimation of efforts.

  1. The legacy product is implemented by the team, which feel comfortable with the software. That raise the emotions :” We’ve done it, it’s easy, we can do it once more”
  2. With one step all the tasks of the entire application are asked to be estimated. That’s a huge bunch of activities.
  3. In a review of one’s task in the past, there is hindsight bias responsible, which changes the way we think to remember us at initial estimations. Hindsight Bias cause, that we believe, we had once estimated risks and efforts more correctly after the event has gone.

There are a lot of psychological articles written about planning fallacy (the phenomenon in which predictions about how much time will be needed to complete a future task display an optimism bias and underestimate the time needed © Wikipedia)
confirmation bias (the tendency to search for, interpret, favor, and recall information in a way that confirms or supports one’s prior beliefs or values © Wikipedia) and in minor part the Dunning-Kruger-effect (the team is familiar with Oracle Forms, but perhaps not with APEX, so they evaluate the estimation with there expertise in Forms, even if they have not the same ability in APEX)
which causes the estimation for an overall project effort dramatically low rather than realistic.

You should be aware of this cognitive bias and try to guide your team into the right direction. Calculations based on a mathematical model of the software don’t step into these biases and could help to start with a more accurate estimation of the complete effort.

This might also interest you:
Process Mining (not just) for Legacy Applications – this is how it’s done!

Further information:
PITSS Corporate Communications
Cathrin Cambensi
ccambensi@pitss.com