Databases are your most expensive, most complex and your most valuable asset. Migrating from one database technology to another is not something that was common practice in the past. With many organizations engaged in digital transformation, in which the cloud plays an important role, database migration is a hot topic when it comes to creating freedom and flexibility to take maximum advantage of it in the future.
A database very often contains valuable business logic that may not be lost. This must be taken into account when migrating an Oracle database to PostgreSQL. Migrating business logic is a delicate process, because many dependencies have to be taken into account. This makes manual migration very time-consuming and almost impossible.
When we started developing our migration software, now known as Cortex, our goal was to automatically migrate the business logic in an Oracle database to native PostgreSQL in order to preserve these past investments. Of course, the tables and suchlike also need to be migrated automatically, but overall that is much less exciting.
To translate business logic (represented in packages, functions, procedures, constraints, views etc.), which is stored in the Oracle database, parsing techniques must be used which take into account the context in which the business logic must function. The business logic has dependencies to tables and columns within tables, but it can also use views and the views can use functions (we won’t make it more complex). All in all, during the migration all these dependencies must be taken into account almost continuously. For example, if a function uses a view, this view needs to be migrated first, but if this view in turn uses a procedure, this procedure needs to be migrated first before continuing with the migration of the view and then continuing with the migration of the function.
Cortex, our product for migrating Oracle databases to native PostgreSQL, is fully equipped for this and therefore Cortex is able to migrate an Oracle database in a highly automated manner.
The so-called “silver bullet” does not appear all at once. There are situations in which pieces of business logic cannot necessarily be migrated automatically. Always unfortunate, but that’s fact of life. Cortex and Splendid Data deal this with respectively in two ways. Where technical errors are found during the migration, based on automated code checking, Cortex issues them so they can still be adjusted manually. We keep in close contact with our customers who use Cortex. The input we get from specific cases that are not properly migrated by Cortex is analysed by us and Cortex is adjusted accordingly where possible.
Our credo is “freedom and flexibility”. This means that there is no vendor lock-in of any kind during the migration from Oracle to PostgreSQL. That is why we always migrate to native PostgreSQL. It is up to you where the database migrated to PostgreSQL is deployed…on premise, in the Azure, Google or Amazon Cloud all freedom of choice is guaranteed. As simple a possible… we deliver the benefits of PostgreSQL.