Lessons Learned: our OWB converter versus the Oracle migration utility

Last week we spoke about our OWB to ODI conversion solution. Some people asked what the differences are with the Oracle Migration Utility.

To be clear: we can and have used the Oracle Migration Utility or our Utility. As a customer it is your choice, but you will certainly appreciate our features.

Here it comes, we support:

  • OWB 10.2 and above
  • ODI 11and above
  • all OS platforms

Regarding ODI Knowledge Modules

We use Customized Knowledge Modules (that can be further customized if needed). Sets all options to recreate the same behavior of OWB Mapping automatically. Our Customized Knowledge Modules were used for past conversions and are in continuous development. We have also enough ODI Knowledge to improve all different features that the customer could want.

Oracle uses the Internal ODI Knowledge Modules (hidden inside ODI, no further modifications possible). If you want to change the used KM, you have to open all Mapping, change the KM and set all the correct options.

Regarding Models and Datastores

Only objects used in OWB Mapping are reversed engineered using the Oracle DMBS Production Environment .

All Metadata are synchronized with the current version of DBMS (Column, Datatype, Length, Scale, Primary Key, Unique Index, Foreign Key). We create exactly the correct number of ODI Models related to all OWB Locations. Simply pre-Conversion management of objects without OWB Location.

Oracle creates an ODI Model for each Oracle Module (ODI Model must correspond to OWB Location, not to Oracle Module. Oracle doesn't manage an "Unknow Location" (you have to fix this manually in your OWB Project before the conversion). Reads OWB Metadata and creates all ODI Datastores (also useless objects or not synchronized objects). After conversionyou have to merge the ODI Model, which means that you also have to change the ODI Mappings using the ODI Datastore from the Merged Model.

OWB Refactoring to the ODI Topology/Model/Datastore can ask a lot of work and can have an impact on the work to do for ODI mappings. Correct ODI Topology/Model/Datastores are critical success factors in a migration. That is why in our initial customer assessment we spend time to analyze and model this and we create the final result manually

Topology

Together with the customer we discuss and implement the architecture. Once decided we create and test this in our own environment.

Once tested we provide the customer the code and instructions to create the exact same topology as agreed and tested. Oracle creates one ODI Dataserver for each ODI Model created (where, we will have an ODI Model for each OWB Oracle Module. This means that after conversion you have to merge a lot of new DataServers because it is not only useless but also very dangerous that two or more DBMS Schemas of the same DBMS instance are created in different ODI DataServers.

Why? If one ODI Mapping loads data from one ODI Datastore to another ODI Datastore, that is part of a different ODI Dataserver, ODI must create a Loading phase (typical using DB Link). If both ODI Data Servers are connected to the same instance an operation of this kind is useless and it will also have very bad performance.

Benefits

  • Works for all OWB and ODI releases
  • Full service: including migration and customization
  • Fast: within weeks
  • Fixed timeframe and fixed price

For more information, see our OWB to ODI page or download our OWB to ODI Migration White Paper

Picture of Rene De Vleeschauwer

About the author

Hello, my name is René De Vleeschauwer.

Throughout my career I've been responsible for the development of enterprise software. Since 12 years I've been leading the development of IKAN ALM, an open DevOps framework.

Do you have any questions about this post? Just ask me!

Get free insight!

Let's analyze your current development and release process, and show you how to make it much faster and 100% reliable.

Yes, I want insight

Souhaitez-vous recevoir les dernières informations et les mises à jour?