As part of our ongoing journey to simplify and automate Oracle to PostgreSQL migrations as much as possible, Eviden and Splendid Data performed a new comparison / evaluation between Cortex (2024.3) and Ora2Pg (v24.3) to understand the differences between the two Oracle to PostgreSQL migration solutions. This comparison / evaluation focuses on the level of automation in database migrations and optimizes both cost-effectiveness and operational efficiency.

To ensure objectivity, Eviden performed the assessment / migration with Ora2Pg, while Splendid Data performed the assessment / migration independently with Cortex. Upon completion, both parties assessed, discussed and documented the results.

The insights and findings from this comparison are intended to guide organisations in making informed decisions for seamless, cost-effective Oracle to PostgreSQL database modernisation, and to support organisations in the seamless transition from Oracle databases to PostgreSQL (on-prem and / or in the cloud). For the initial comparison / evaluation between Cortex and Ora2Pg conducted in 2022, also in collaboration with Eviden, see here.

What did we do

• The equation between Cortex 2024.3 (hereafter: Cortex) and Ora2Pg v24.3 (hereafter: Ora2Pg) is performed by Eviden and Splendid Data.
  • Eviden provided an Oracle database with enough complexity (169K net Lines of Code PL/SQL) to be used as a reference.
  • Eviden performed the assessment / migration with Ora2Pg.
  • Eviden provided Splendid Data with the applicable Oracle Catalog Views.
  • Splendid Data performed the assessment / migration with Cortex.
• Results from both assessments / migrations are shared and discussed.

Assessment results

In this table you will find the schema objects on the left side, with the second column the number of objects available in Oracle. The third and fourth columns presents number of Oracle objects taking into account in the assessment by respectively Cortex (2024.3) and Ora2Pg (v24.3).

Numbers and facts:

We have highlighted the most notable results and provided explanations for the significant differences in the estimated time required and the more realistic estimated work hours:

• What Cortex detects is similar to what the Oracle database contains (9.127 objects DDL and DML). Ora2Pg detects approx. 48% less to what the Oracle database contains (5.136 objects DDL and DML).
• Cortex took all 1.184 functions/procedures included in Package Bodies into account, and Ora2Pg took only 64 functions/procedures included in Package Bodies into account (95% of the functions/procedures in the Package Bodies are missed by Ora2Pg).
• Cortex gives detailed insights in the complexity of the Oracle database and shows exactly what went well and what went wrong during the assessment. Regarding the DDL/DML approx. 83% of all objects will be migrated automatically to native PostgreSQL. The time needed to perform manual adjustments (excl. Job Scheduling and Advanced Queuing) with Cortex will take 124 work hours.
• Ora2Pg gives detailed reports, but doesn’t report that it missed for instance 1.120 (95%) of the functions/procedures that are included in Package Bodies and failed to migrate 321 triggers, but gives an estimated time to finalize the Oracle to PostreSQL migration (excl. Job Scheduling and Advanced Queuing) of 255 work hours.
• Manual migration of all the 1.120 functions/procedures that are included in Package Bodies will take at least 2.240 work hours (in average 2 work hours per function/procedure), and the manual migration of the 321 triggers that are not migrated will take at least 321 work hours instead of the 95 work hours reported. All and all…a better estimate time to finalize the migration based on the Ora2Pg (excl. Job Scheduling and Advanced Queuing) would have been at least 2.721 work hours.

Migration

Cortex

• Before starting the migration 2 data types were adjusted to solve foreign key mismatches (via Cortex Data Remap functionality) and table partitions were set to migrate (via the Cortex Miglists functionality).
• Migrating the DDL and DML (all together 9.127 objects incl. 169.431 net Lines of Code PL/SQL) took approx. 5 hours computer (processing) time. Approx. 83% of all the DDL/DML objects are automatically migrated to native PostgreSQL. All manual adjustments to finalize the migration are reflected in Jira issues. Time needed to finalize the migration (excl. Job Scheduling and Advanced Queuing) is 124 work hours.

Ora2Pg

• The necessary settings were set. Ora2Pg has so many settings that you can’t see the forest for the trees and have to spend a lot of time for the best result.
• Migrating the DDL and DML (all together 5.136 objects incl. approx. 10.000 Lines of Code PL/SQL) took approx. 2 hours computer (processing) time. It missed 1.120 functions/procedures in the Package Bodies (approx. 140.000 net Lines of Code PL/SQL). Time needed to finalize the migration is 255 work hours (excluding the 1.120 functions/procedures in the Package Bodies and the 321 triggers).
• The results of the migration are delivered in a project structure. It is very unclear what has been migrated and what has not, and what went well and what not. This has to be sorted out manually.

Overall conclusions

Cortex

• Cortex is much more efficient (user friendly) and effective…you really can master your assessments / migrations.
• Delivers many detailed reports, a GIT repository with all the results and a Jira / DevOps population file to manage your manual adjustments.
• The time needed to perform an assessment / migration via Cortex takes more time (approx. 5 hours computer time), but you only need 124 hours (expert level) for manual adjustments.
• After migrating you only need 124 expert level) for manual adjustments.
• The cost of using Cortex to assess and migrate an Oracle database technically to PostgreSQL is a one-off. After the migration it is no longer needed and leaves no footprint. Are you wondering what the license cost will be for your database? Contact us, we are sure you will be surprised. We are absolutely sure Cortex saves you a lot of time and money.

Ora2Pg

• Complex in usage and less effective…hardly any support provided to master your assessments / migrations.
• Hardly no reports that tells you what to do after performing a migration. Find out yourself manually.
• Most likely you will need at least 2.721 hours (expert level) for the manual adjustments instead of the 255 work hours reported.
• Ora2Pg misses 56% of the Oracle objects (incl. 95% of the functions / procedures in the Package Bodies) to be translated in this reference database in comparison with Cortex.
• Ora2Pg will require at least 2.240 work hours (approx. 2 work hours per function/procedure in the Package Bodies missed by Ora2Pg) and the 321 work hours related to the triggers instead of the 95 work hours reported on top of the estimated 255 work hours for manual effort to translate this reference database. In total at least 2.721 work hours are needed, compared to the 124 work hours needed when using Cortex.
• Ora2Pg no license cost…it’s for “free”.

Business case

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.

• The cost of finalising the migration after Cortex did its work will be € 18.600 (approx. US$ 20.460), based on 124 work hours at € 150 per work hour (expert level).
• The cost of finalising the migration after Ora2Pg did its work will be € 408.150 (approx. US$ 448.985), based on 2.721 work hours at € 150 per work hour (expert level).
• Cortex has a much better TCO and is much more efficient and effective than Ora2Pg especially when an Oracle database contains DML (PL/SQL).

Cortex is cheaper than free…and for this migration from Oracle to PostgreSQL at least 90% cheaper than free!

Would you like to know more and are you curious about the cost of using Cortex? Contact us, we are sure you will be surprised. We are absolutely sure Cortex saves you a lot of time and money.