Oracle forms migration: The Story

The challenges

1. Legacy technologies: Oracle will discontinue support for OracleForms and OracleReports at the end of 2025. As a result, customers are unable to use our Product because it violates their contract. The two legacy technologies must be replaced with modern ones, in this case, C# for backend services and Angular for front-end.
2. Architecture modernization: Application migration from legacy technologies involves both technical and business modernization. From a technical standpoint, the OracleForms application is transitioning from desktop to web technologies, which presents a number of challenges. From a business standpoint, the unit's working methods must evolve to meet the demands of the migrated application's modern approaches.
3. Business knowledge is scarce: Business knowledge about the application is concentrated in the hands of a few people, some of whom are consultants and others are product owners. Consultants are naturally busy with customer demands and have little time to devote to the migration process. The product owners are few (actually two) and do everything they can to help with the migration process, but this is not always possible due to the OracleForms application's numerous functionalities and customer options. Because of the circumstances in the unit, the migration process agreement states that a best-effort is acceptable, and the resulting software will be further improved once the migration process is completed.
4. Providing high-quality to the migrated application: Our Product is an OracleForms/OracleReports application that has been in production for over 30 years, with a large set of features and customer options. The application includes approximately 750 forms (equivalent to around 1500 web pages) and 380 reports. With such a large application and limited business knowledge available, performing QA on the migrated application is difficult, but possible with modern approaches.
5. Application performance: Our Product is based on OracleForms technology and an Oracle database. The technology stack has been in production for a long time and has been refined to provide superior performance. Migrating the application to a client-server architecture using non-Oracle technologies may result in reduced application performance.
6. Meeting the deadline: Since OracleForms/OracleReports will be phased out of support at the end of 2025, the hard deadline for providing a migrated solution is around the end of 2025. With approximately 750 forms and 380 reports, there is a race to provide a modern application to customers. Agility must be our middle name, and it is what inspired the codename Cheetah - we are constantly looking for ways to improve technical, business, and process aspects with the goal of meeting the set deadline. An additional consequence of the support drop is that the migration process needs to be 1-to-1 (as much as possible).
7. OracleForms / OracleReports proprietary technologies: Oracle owns the legacy technologies, and we do not have access to their inner workings. This makes replicating the behavior challenging and time-consuming.

The idea is to feed the black box some input and observe the output. Based on the given input and the received output, the black box behavior is implemented in .NET.

Our current endeavor is not to rebuild the entire execution engine from OracleForms, but only the part that is used by Our Product. We are not set to observe all possible state mutations from OracleForms, but only those used in Our Product.

As the application functionality is observed, patterns emerge, which can lead to generalization of behavior. Complex behaviors observed within the application are actually compositions of simple atomic actions (or state mutations) that appear based on user input (e.g., atomic actions are enter-query, query, insert, update, delete, commit, navigation from record to record, navigation from item to item, etc.).

• OracleForms UI engine:

Blackbox migration into Angular with front-end Design System (replicate UI/UX based on agreements with the business). This engine is simpler in nature as it renders on the browser window the state presented by the backend engine. The OracleForms layout is described in XML format and is translated into the JSON format required by the UI engine using an internal tool.

OracleReports migration has a similar approach, but the components are simpler in nature

• Triggers & programming units: PL/SQL source code, which is translated into C#.
• Output generation: output layout is described in XML format in OracleReports and is translated into C# using an internal tool.

Job done, our new product is in production and tested by current customers!