The Eviden Database Modernization program aims to convert legacy databases to open source or cloud databases at the highest level of automation for the lowest cost. And so to help our customer make the best decision for their business, in terms of the best product to migrate Oracle® databases to PostgreSQL, we agreed to do a comparison between Splendid Data’s Cortex and Ora2Pg to gain insight into the differences between them.

Eviden selected a reference Oracle database of sufficient complexity to ensure it was representative of the type of databases that their enterprise customers are planning to migrate. The reference Oracle database contained approx. 160,000 Lines of Code PL/SQL (packages, package bodies, functions and procedures), including approx. 6,700 Lines of Code SQL related to views.

To ensure complete impartiality, Eviden performed the assessment and migration with Ora2Pg and Splendid Data performed the same tasks with Cortex. After both had carried out their work, the results were exchanged and discussed, and reflected in findings and business cases.

Assessment phase

The differences between Cortex and Ora2Pg were considerable. During the assessment (see results table below) it appeared that Ora2Pg didn’t recognize more than 50% of the objects in the assessment. Yes, over half. This largely related to the objects linked to the business logic (DML) in the Oracle database. About 95% of the functions and procedures defined in the Oracle Package bodies were not recognised by Ora2Pg at all.

Estimated time of migration

Both Cortex and Ora2Pg gave an estimated time, in work hours, for completing the migration – these are the work hours required to carry out any manual adjustments. The results that came back were surprising. Ora2Pg provided an estimate that was more than twice as long as Cortex. Added to this, Ora2Pg didn’t detect the majority of the business logic – this would dramatically affect the accuracy of the estimated manual time needed to complete a migration. In contrast, Cortex provided insight into 100% of the objects in the Oracle database which creates a far more solid base for a time estimation.

After the assessment results had been completed and discussed, we took both Ora2Pg and Cortex into the migration phase.

Migration phase

Going through the migration phase we could see that Ora2Pg did in fact, leave out most of the business logic (DML). Eviden made several attempts to carry out the migration with Ora2Pg with different settings, but the results did not improve. Cortex, however, was at the other end of the scale and was able to migrate nearly 100% of the Oracle data objects (DDL) and approx. 71% of the Oracle code objects (DML) to native PostgreSQL.

Let’s look at the mutual findings from the assessments and migrations

 Ora2Pg

• Ora2Pg is complex to use and not so effective for this type of database, and there’s hardly any support to master your assessments and migrations.
• Ora2Pg delivers hardly any reports after performing a migration, so you’d have to find out the details when you manually do the migration.
• In this example, to migrate the reference database, you would likely need at least 2,733 hours (expert level) for the manual adjustments, calculating 2 hours per function/procedure that are missing (readjusted for 100% of the business logic).
• The good news for Ora2Pg is that there’s no license cost…it’s free.

Cortex

• Cortex is more efficient, user friendly and effective, plus you can really master your assessments and migrations.
• Cortex delivers many detailed reports such as a GIT repository with all the results and a Jira population file to manage your manual adjustments. As a result, it supports a DevOps way of working.
• With Cortex you would need 201 hours (expert level) for manual adjustments for 100% of the Business logic.
• The cost of Cortex to assess and migrate this complex Oracle database is €4,800. (note : the license costs of Cortex vary with the assessed complexity of the database to be migrated).
• The good news: The total cost of migrating the database with Cortex is much, much lower than with Ora2Pg…see the business case below.

Now let’s look at the numbers

 Ora2Pg

The total cost of the migration using Ora2Pg would be € 273,000 (see breakdown below):

• 2,733 work hours at an average rate of €100 per work hour is € 273,000.
• License cost of Ora2Pg is € 0/US$ 0.

Cortex

The total cost of the migration using Cortex would be € 24,900 (see breakdown below):

• 201 work hours at an average rate of € 100 per work hour is € 20,100.
• License cost of Cortex is € 4,800.

A clear winner – Cortex!

From this assessment and migration, we can see that for just one database, you would spend 2,500 hours less of your development capacity. Naturally these hours could be better spent bringing more IT-benefits to your business – let alone the obvious cost implications.

It’s clear that Cortex has a far superior TCO and is much more efficient and effective than Ora2Pg, especially when an Oracle database contains DML (PL/SQL).

Free is not the cheapest. In fact, in our test it cost at least 10x more overall.

“After this comparison, Eviden will definitely be advising customers who wish to migrate Oracle databases to PostgreSQL as part of their database modernisation, to choose Cortex. It’s clear they will save on migration costs, the migration project duration and enjoy the added benefits of user friendliness and better control.”
–– Erik Cramer, Eviden Global Portfolio Director Database Modernization

To learn more about Cortex in detail, you can download our white paper about Cortex. There’s nothing like a face-to-face though, and we’d be happy to demonstrate how Cortex can reduce the footprint of your Oracle databases. Cortex really is the fastest, smartest, easiest and the cheapest way overall to migrate your Oracle database to native PostgreSQL – start your journey today.

Additional information:

Oracle database migrations is a hot topic when it comes to creating freedom & flexibility and cutting costs. And we understand that before you start migrating your Oracle databases to PostgreSQL, you will first want to fully understand what the overall impact will be. So, take a look at our overall approach.