Migrate from Oracle to Postgre by automating the process!

 

Migrate from Oracle to Postgre by automating the  process, for a flat rate  ! Many companies are moving from Oracle to PostgreSQL   Oracle Database has a reputation for being expensive in terms of licenses and support.  This pricing policy may make Oracle less attractive to some companies. Bloomberg notes a decline in new license sales at Oracle. A decline that has been continuing for 7 quarters.    On the other side, we have the PostgreSQL database,  which is free, can be modified and distributed, has a reputation for being reliable and stable, with good transaction management... All these elements make it suitable for critical applications where data consistency is essential. PostgreSQL also supports a wide variety of data types, including geospatial types, JSON, etc., which makes it suitable for handling complex and varied data.     Postgre is now the 4th most used database in the world, with significant growth rates .   But it remains a difficult movement to initiate.   According to Carl Olofson, research vice president at IDC, "There are a number of Oracle users who would like to try PostgreSQL for at least part of their workload, but are discouraged by the risk and cost of conversion." It must be said that PL/SQL, Oracle's procedural language, began to be used in 1991. It is the most widely used procedural language in the world! It offers the ability to write complex data manipulation functions without resorting to a third-party language. As it is a query language, it allows you to make fairly complex scripts: functions, procedures, triggers, apex, etc. PL/SQL is not migratable as is to Postgre. At least, not simply. These  migration projects  are often long and expensive projects, and sometimes failures.    But not necessarily  .   We have developed a proven, 2-step methodology to mechanically make this migration a success, on a flat-rate basis when the Oracle DB is primarily used as a data warehouse with PL strings.   Step #1: Simplify the system in source Log analysis by  {openAudit} ,  our software, allows us to detect information that passes through dataviz tools and in all queries (JDBC, ODBC, etc.). The data lineage of  {openAudit} , by tracing all the flows that generate real usage, makes it possible to define the useful vs. useless parts of the Information System.  It becomes possible to carry out massive decommissionings upstream of the migration. Fine-grained introspection of flows in databases allows  {openAudit}  to factorize code. Zoom in / Zoom out in an Information System Step #2: Technically migrate from Oracle to PostgreSQL {openAudit}  will “parse” the PL/SQL, it will break down all the complexity of the code thanks to a grammar allowing exhaustive and ultra-granular analyses.  All the subtleties of the PL/SQL will be taken into consideration.  {openAudit}  deduces the  overall kinematics  and intelligence, which will be reconstructed in an agnostic algorithmic tree (this could be simple Scratch). Based on this,  {openAudit}   will produce standard SQL. Then the intelligence will be reconstructed at least in the PgSQL by  {openAudit} . Some complex processing, not reproducible in simple SQL, will be driven by a NodeJS executable.  Typically “For Loop” cursors, variables, “If Else” conditional code, “Switches”, procedure calls, etc.    Eventually, new orchestration mechanisms can be implemented to deconstruct cursors of cursors (loops of loops), or to optimize transformation chains*. So, generally speaking, it is possible to decommission Oracle assets and reproduce all of their intelligence in PostreSQL in an extremely efficient way.    We are committed  : migrations  are  carried out on a fixed price basis. *There are some limitations:  Unit procedures called by external code or triggers  can be subject to ad hoc responses.