Replacing Oracle — when it pays

We run both Oracle and PostgreSQL. That is why we can also tell you when a migration is not worth it.

Moving from Oracle to PostgreSQL saves licence and support costs permanently. What the move itself costs is established far less often — and that is where projects come apart: the fees saved are quickly calculated, the effort for porting, testing and cutover is not. We establish both sides before a decision is taken.

PostgreSQL is our standard target. We also implement MySQL and MariaDB on request; for replacing established Oracle applications, PostgreSQL is usually the better fit, because it sits considerably closer to procedural logic and to the Oracle constructs your team already knows.

The core of our approachthree times, not once

Run 1

validation of the technique and verification of functionality

Run 2

migration runtimes, comparison against the performance baselines, overall performance of every application accessing the database — and the fallback plan is exercised end to end

Run 3

the final migration — along a path that has been fully rehearsed twice

Phase 1: initial analysis at a fixed price

The starting point is our cost and licence review at a fixed price. It establishes what your databases cost today, which options are genuinely in use, and how the availability architecture is set up. From this follows one of two outcomes: either optimising what you have is the better route — in which case we say so — or a migration comes into consideration. The deeper analysis follows only in the second case.

Phase 2: detailed analysis

It builds on the data gathered in the initial analysis rather than collecting it again.

Database

We assess the complexity of the Oracle database: the data types in use, the size of the tables, the Oracle options in use, and the volume and complexity of the existing PL/SQL objects. In our experience it is not the data volume that determines the effort but the procedural code — schema and data move comparatively quickly.

Added to that is the workload of the instances: I/O behaviour, wait events and the utilisation of the hardware resources. We also capture baselines of the SQL statements being executed. Those baselines are later the yardstick against which the new platform is measured — without them, any performance comparison remains an assertion.

Dependent applications

We examine client access and the connections in use in order to estimate the migration effort on the side of the applications, interfaces and users. This side is regularly underestimated and is often a larger construction site than the database itself.

Infrastructure

We look at the existing Oracle infrastructure including Active Data Guard, RAC installations and GoldenGate replication, as well as the licences in use. For each of these components we establish whether it is carrying real business requirements and how it is to be represented on the target platform.

Soft factors

Just as important as the technology: which database technology can your organisation realistically support in-house? A migration your operations team does not carry trades a licensing problem for an operating problem. We ask that question early and honestly.

Phase 3: scenarios and commercial assessment

From the facts gathered we develop possible migration scenarios and assess them commercially. Two questions are central:

Does a move into a public cloud make sense as well — or does it merely shift costs from licensing into operations?
What does the migration itself cost, and how do the costs behave on the new platform in day-to-day operation?

Open-ended: "stay and optimise" is a legitimate outcome of this assessment. We earn our money on migrations — which is precisely why we say in advance when one does not pay. Extensive PL/SQL logic at the core of the application, packaged software certified for Oracle only, or a workload profile that genuinely requires RAC all argue against it.

Phase 4: migration

Depending on the target environment, the complexity of the database and the availability requirements during the changeover, different techniques come into play. Among others we work with the AWS Database Migration Service, with ora2pg, and with oracle_fdw, PostgreSQL's foreign data wrapper for Oracle.

As a rule we carry out the migration three times:

Run 1 — technique and function: Validation of the chosen procedure and verification of functionality. This is where it becomes clear which constructs cannot be transferred automatically.
Run 2 — runtime, performance and fallback: Testing of the migration runtimes and validation of migration performance. Comparison against the database performance baselines captured earlier, and assessment of the overall performance of every application accessing the database. In the same run the fallback plan is exercised end to end — not described, but executed.
Run 3 — the final migration: The actual changeover, along a path that by this point has been fully rehearsed twice. Runtimes and outcome are no longer an estimate.

How the changeover itself runs — the outage window, the sequence, responsibilities, abort criteria — is worked out in a workshop with everyone involved. A changeover rarely fails on the technology and frequently fails because, at the decisive moment, it is unclear who decides what.

Phase 5: operating the new platform

After the migration we continue to operate PostgreSQL for you on request: high availability with Patroni, backup and recovery with pgBackRest, 7×24 operation under firmly defined SLAs. Our references show what that looks like in practice — including the project in which replacing Oracle freed up 16 processor licences of Enterprise Edition.

That puts an end to the most common worry ahead of a migration: that once Oracle support falls away, nobody will be left who knows the platform when it matters.