Any example customer has migrated from Oralce Forms to ADF?

Question

Any benchmark or how many customers have done the migration from Forms to ADF？
Btw, is all kind of Froms convertible by Froms2ADF tools ?
thanks for any suggestion.

Answer 1

Here is my view on this:
In general, people tend to underestimate the effort involved in migrating from Forms to ADF.
Migration tools like the JHeadstart Forms2ADF Generator can be of help, but are by no means a silver bullet.
When does JHeadstart save time
The amount of work that can be saved by using the JHeadstart Forms2ADF Generator (JFG) very much depends on the structure of the Oracle Forms application at hand. The JHeadstart Forms2ADF Generator provides most savings for forms that have the following characteristics:
- Standard-Forms data retrieval and data manipulation through blocks based on database tables, with master-detail relations defined between the block
- Complex user interface, many (stacked) canvasses, many tabs, many list of values, and other display types
- PL/SQL logic mostly limited to user interface dynamics: conditionally showing/hiding user interface items, and conditionally changing the properties of user interface items. While JHeadstart does not convert PL/SQL logic, this type of logic is easily implemented in the ADF application because JHeadstart provides many declarative property settings to implement this behavior.
PL.SQL Logic
JHeadstart has made the deliberate choice to not automatically convert the PL/SQL logic to Java. The reasons for this are:
- It is impossible to automate the migration of a two-tier architecture (logic in Forms or in the database) to a three tier Model-View-Controller architecture as is common in JEE web applications, including ADF-based applications.
- The architecture of the converted application should be identical to the best-practice architecture of an ADF application that is build from scratch. If the architecture is the same, the same skill set can be used to maintain both migrated applications and ADF applications build from scratch. In addition, by going for a best practice architecture, the application is more flexible, and can be maintained easier at lower cost.
- When using the JHeadstart Forms2ADF Generator, you get this best-practice ADF architecture that is identical to ADF/JHeadstart applications that are built from scratch.
Other Forms2ADF Considerations
Even if it turns out the JFG adds value, there are many other questions the customer should ask himself before embarking on a Foms2ADF project. For example:
- Apart from technical reasons like old Forms verisions no longer supported, are there real business reasons and business benefits for migrating that justify the migration effort?
- To what extent is the application still meeting functional requirements?
- Are there issues with stability and end user friendliness?
- Old forms applications are typical "window-on-data" screens, you see the structure of the datamodel through the layout of the screens. Modern web 2.0 composite applications are more task-oriented with good support for human workflow. The customer should consider to what extent it wants to leverage all these new user interfaces capabilities that come with ADF Faces and WebCenter.
- How does the application fits in the overall IT landscape of the customer? What interfaces to other systems exist, what (old/obsolete?) technology is used to implement those interfaces?
- What about batch functionality and reporting facilities?
- May be part of the functionality of the current system can be replaced with standard off-the-shelf software?
- How sound, well structured and future proof is the underlying datamodel?
- To what extent is the customer looking at service-orientated architectures? Whats the SOA maturity level of the customer?
- Above questions help to answer the key question: how desirable and beneficial is it to migrate an old monolitic forms application 1:1 to a monolitic ADF aplication? How does that fit in overall IT strategy?
- Organisational isues: who will migrate the system, who will maintain the system? Is outsourcing considered? etc.
Some customer experiences
Over the years I have been involved with a number of customers that migrated from Forms to ADF. With some of these customers we used the Forms2ADF Generator in the proof-of-concept phase to convince them of the combined power of ADF and JHeadstart. However, with NONE of these customers we used the Forms2ADF Generatpr during actual migration, for various reasons as listed above. All customers eventually chose to truly re-engineer the application while rebuilding in ADF achieving signifcant new business benefits that justified the investment. A choice recommended and encouraged by me, despite the fact I am the creator of the JFG. Note that ALL customers use JHeadstart heavily forbuilding the re-engineered ADF application, they just don't use the Forms2ADF generator, but the JHeadstart Application generator to create the ADF app from scratch.
Other resources
You also might want to take a look at the following presentations:
- http://www.slideshare.net/stevendavelaar/forms2-adfsoa-ukoug
- http://www.slideshare.net/stevendavelaar/jhs11-forms2-adfukoug
- http://www.slideshare.net/oracle_imc_team/oracle-forms-modernization-strategies
- http://www.slideshare.net/lucasjellema/forms-2-future-the-ongoing-journey-into-the-future-for-oracle-based-organizations
Hope this helps,
Steven Davelaar,
JHeadstart Team