We’ve been getting a lot of inquiries asking whether we have a tool that will automatically convert Oracle Forms applications to Formspider.
We don’t have an automatic converter. We don’t view this as a disadvantage at all. We are solving the modernization problem with a different approach:
Formspider does not automatically converts your Forms applications to web apps but it converts your Forms developers to first rate web developers.
We think this approach produces the best results and lowest cost in conversion projects. We’ve seen this many times.
Formspider is an application development framework just like Oracle Forms and just like Forms its programming language is 100% PL/SQL. (You can think of it as Oracle Forms built for 21st century.) Because Formspider works very similar to Oracle Forms (event driven architecture, Formspider built-ins instead of Forms built-ins etc…) it is an order of magnitude easier to learn for Oracle Forms developers compared to any other tool.
A conversion project using Formspider is not a complete rewrite where you start with a blank page. This is absolutely not true. Just to give few examples; All of your existing business logic implemented in PL/SQL can be reused in your new application. And because both Forms and Formspider are event driven and use similar API’s, code that manages the UI can be translated fairly easily. In other words, there is no impedance mismatch between the two products unlike between Forms and (say) ADF, .NET or any other popular web development framework.
There are several problems with automatically converting Oracle Forms applications to another tech stack:
1) The new target tech stack is not known by your team
I cannot overstate how important this is. You end up with an application that you cannot maintain. Your team, who knows the business, who knows what your customers want, who obviously can deliver a successful application to the users, needs training in the new tech stack. This means they go back to becoming junior developers for quite some time. (Even the most zealous ADF proponents admit to a year or longer learning curve.) This feeling of helplessness is very frustrating for experienced developers who know exactly what they wants to implement. It hurts the team moral and motivation during the project. It’s also very costly because, well, training costs money and the output of the developers lower significantly for months but their salaries do not.
2) The output of an automatic converter is usually of low quality
Almost always the target tech stack uses the web page paradigm instead of the event driven architecture of Forms. This impedance mismatch is very very difficult to overcome automatically and the customer ends up with a low quality application design that no engineer would architect by himself. This makes the application very difficult and expensive to maintain.
Moreover, if the target tech stack uses an object oriented programming language, this adds another magnitude of complexity because PL/SQL is not object oriented. This is why most automatic conversion projects start with the manual process of moving as much code to the database as possible.
3) Automated converters are expensive
Best to my knowledge these converter tools are not cheap at all. These tools come with bundled services (they never get the job done 100% automatically) so you also pay for consulting services on top of the conversion fees.
Formspider customers around the World have been upgrading their Forms applications with Formspider successfully for years. The same team who built and maintained the Forms applications builds the application in Formspider. They get excited and motivated because finally they have a tool that they can use to build what they want. They feel empowered instead of helpless. The cost savings we provide might be up to hundreds of thousands of dollars depending on the size of your application. I have seen this over and over again many times:
Put Formspider in the hands your Forms developers and they will modernize your Forms applications with the highest return on investment.
Yalim K. Gerger