Design Goals for the Oracle APEX Application Migration Workshop

We are in the home stretch now, to make the early adopter version of the Oracle APEX Application Migration Workshop available on OTN. We have released some more information about it on OTN and have created a new OTN forum to host discussions about migration from Microsoft Access to Oracle Application Express.

I thought it would be an opportune time, to outline some of our design goals behind this development. Firstly, we want to promote Database Refactoring, once you have gotten your schema and data migrated using the Oracle Migration Workbench. The better your Data Model is, the easier it will be to create good Oracle APEX applications. Currently we identify tables without primary or foreign keys and also promote the usage of UI defaults, a feature of Oracle APEX. We hope to expand on this in the future, based on feedback. A possibility could be to identify tables that could be leveraged as List of Values (LOV's) or try to identify incorrect usage of data types, e.g. dates being stored as varchar.

Our approach is one of Design Recovery. We want to provide as much information about the original Access Application that we could recover from the Access mdb file. We have taken a workshop approach, to provide the developer a productive environment to decide what Access objects they are interested in and should be in scope. You deal with any errors reported, so additional objects can also be included. By default all Access objects which we analyze and determine are valid are included in the scope your migration project by default.

Our goal is to only generate a native Oracle APEX application. We are not interested in emulating unique Access functionality. Access Applications could be classed as "rich client" applications whereas Oracle APEX applications are Web (Browser) based. It's a different UI paradigm, and this needs to be respected if you are to create, intuitive and useful applications. We don't migrate any VBA code, but we will show you the VBA code contained in your modules. You could then determine if this logic is still necessary and if so, could be reimplemented as PL/SQL procedures/functions.

We can generate either an application based on selected Access Forms or Reports or generate a maintenance style application which is a Report and a Form on each selected Tables and Views.
Our application generation leverages the Application Model behind the create application wizard.

I am looking forward to feedback on this new feature of Oracle APEX. I believe we have built a good foundation, to address additional feature requests we might receive. With input from the community we can ensure that the Application Migration Workshop increases the productivity of developers who seek to migrate Access applications to Oracle APEX, when it becomes a standard feature of Oracle APEX 3.0

Now back to the last round of testing...