Projekt Digital

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.

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.

The advantages are:

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

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.

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.

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.

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.

• 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.

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.