Work through all 20 items. Mark each as feasible (✓), risk (✗), or unknown (?). High-risk items represent the most common causes of Oracle-to-PostgreSQL migration failure or cost overrun. Download our Oracle Audit Defence Kit for the licence exit checklist.
Section 1
Pre-Migration Inventory and Complexity Assessment
01
You have produced a complete inventory of every Oracle Database instance in scope for migration — including version, edition, size, and the business systems dependent on each instance.
High
Expert note: Migration feasibility cannot be assessed without a complete instance inventory. Many organisations discover additional Oracle instances during a migration project that were not in the original scope — legacy ETL databases, reporting replicas, DR instances — each adding cost and complexity. Document every Oracle instance: product version, edition (Standard, Enterprise, SE2), physical size in GB, number of schemas, approximate row count for key tables, and every application, report, batch job, or API that connects to it. This inventory is the foundation of every subsequent assessment item.
02
You have performed a Proof of Concept migration for at least one representative Oracle database before committing to a full migration programme.
High
Expert note: A PoC is not optional for any Oracle-to-PostgreSQL migration of material complexity. Oracle's data types, stored procedure language, and SQL dialect differ from PostgreSQL in dozens of ways that only surface when you actually attempt a migration. A PoC on one representative database — chosen for its mix of stored procedures, triggers, data types, and application connectivity — will expose the real conversion complexity, the tooling gaps, and the application code changes required before you have committed to a migration budget or timeline. Treat PoC failures as valuable data, not project failures.
03
You have conducted a full inventory of PL/SQL objects — stored procedures, functions, packages, triggers, and views — in each Oracle database to be migrated, with line counts for each object type.
High
Expert note: PL/SQL-to-PL/pgSQL conversion is the most labour-intensive component of an Oracle-to-PostgreSQL migration. Oracle's PL/SQL and PostgreSQL's PL/pgSQL are similar in structure but diverge in dozens of important details: package scoping, exception handling, autonomous transactions, bulk collect operations, DBMS_OUTPUT, UTL_FILE, and Oracle-specific built-in packages. A database with 2 million lines of PL/SQL code is a fundamentally different migration project from one with 50,000 lines. Count every PL/SQL object before building a migration estimate.
04
Oracle-specific SQL dialect constructs in your application codebase — ROWNUM, CONNECT BY, DECODE, NVL, TO_DATE format masks, DUAL table references — have been identified and quantified.
High
Expert note: Application SQL that works on Oracle will fail on PostgreSQL at runtime. Oracle dialect SQL constructs must be replaced: ROWNUM → LIMIT/OFFSET, CONNECT BY → WITH RECURSIVE, DECODE → CASE, NVL → COALESCE, SYSDATE → CURRENT_TIMESTAMP, DUAL → removed or replaced. The most reliable way to quantify this work is a codebase scan using a tool such as AWS Schema Conversion Tool (SCT) or Ora2Pg — but SCT flags items requiring manual review, not just automated conversion. Do not estimate application code migration based solely on automated tool output.
05
You have identified all Oracle-specific data types in use — including NUMBER precision, DATE (not TIMESTAMP), VARCHAR2, CLOB, BLOB, XMLTYPE, SDO_GEOMETRY, and ROWID — and mapped each to its PostgreSQL equivalent.
High
Expert note: Oracle and PostgreSQL handle data types differently in ways that cause data loss or application failures if not addressed. Oracle DATE columns store both date and time; PostgreSQL DATE stores date only — a common migration error that causes every time-of-day value to show midnight. Oracle NUMBER(38) maps to NUMERIC in PostgreSQL but may require precision adjustments. Oracle CLOB maps to PostgreSQL TEXT; BLOB to BYTEA. Oracle XMLTYPE maps to PostgreSQL XML or JSONB depending on use. ROWID has no direct PostgreSQL equivalent. Document every Oracle data type in use and confirm the PostgreSQL mapping before data migration begins.
Considering Oracle-to-PostgreSQL migration?
Independent technical and commercial feasibility assessment. No Oracle affiliation.
Section 2
Technical Compatibility and Feature Gap Analysis
06
Your Oracle database uses Oracle-specific features — Partitioning, Advanced Security, Label Security, Real Application Clusters (RAC), Data Guard, Streams, Advanced Queuing — and each has been assessed for its PostgreSQL equivalent or migration strategy.
High
Expert note: Oracle-specific features require deliberate replacement planning. Oracle Partitioning maps partially to PostgreSQL declarative partitioning (for RANGE and LIST), but HASH partitioning and interval partitioning require different approaches. Oracle RAC has no direct PostgreSQL equivalent — pgBouncer connection pooling, Patroni HA clusters, or cloud-managed PostgreSQL services are the closest alternatives. Oracle Data Guard maps to PostgreSQL streaming replication. Oracle Advanced Queuing maps to PgQ or similar. Each feature requires independent technical planning — do not assume automated migration tools will handle these.
07
Applications connecting to Oracle via JDBC, ODBC, or Oracle-specific client libraries have been assessed for the effort required to switch to PostgreSQL-compatible drivers and connection strings.
Medium
Expert note: Every application that connects to Oracle must be updated to use PostgreSQL drivers. JDBC connections switch from Oracle's ojdbc to the PostgreSQL JDBC driver (pgjdbc). ODBC connections require PostgreSQL ODBC driver configuration. Oracle OCI-based connections (used in C and C++ applications) require a complete driver replacement. Some ORMs (Hibernate, Entity Framework) can be reconfigured with minimal code change; others require query rewriting. The driver switch is typically low effort per application but high effort in aggregate if hundreds of applications are in scope.
08
Packaged software applications in your Oracle environment (SAP, Workday, custom ERP) have been confirmed as either PostgreSQL-certified by their vendors or are being retired as part of the migration programme.
High
Expert note: Packaged software vendors certify specific database platforms. Many enterprise applications are Oracle-only: if your ERP vendor does not certify PostgreSQL, you cannot migrate the Oracle database underlying it without also replacing the application — a project of a fundamentally different scale. Confirm the database certification matrix for every packaged application before including its Oracle database in the migration scope. Applications that are PostgreSQL-certified typically require only driver and connection string changes; non-certified applications must be excluded from scope or replaced.
09
Your migration strategy accounts for Oracle's implicit type casting behaviour — which silently converts between types where PostgreSQL requires explicit casting and throws errors.
Medium
Expert note: Oracle's permissive type casting causes significant application issues on PostgreSQL. Where Oracle silently converts a VARCHAR2 column containing '123' to a NUMBER for comparison, PostgreSQL throws a type mismatch error. This affects WHERE clauses, function calls, INSERT statements, and any code that relies on Oracle's implicit conversion. Automated migration tools flag some of these issues, but the majority only surface during integration testing. Budget for an extended testing cycle that exercises every data type boundary in your application logic.
10
You have assessed the NULL handling differences between Oracle and PostgreSQL — specifically Oracle's treatment of empty strings as NULL — and identified all application code that depends on Oracle's behaviour.
High
Expert note: Oracle treats an empty string ('') as NULL; PostgreSQL treats them as distinct values. This difference silently breaks application logic that inserts empty strings expecting to satisfy a NOT NULL constraint (Oracle accepts it; PostgreSQL rejects it), and breaks queries that filter for NULL expecting to catch empty strings. The impact is application-level and difficult to detect through schema migration tooling alone. Audit every INSERT and UPDATE statement in your application codebase for empty string handling before migration testing begins.
Section 3
Commercial, Compliance, and ROI Analysis
11
Your Oracle licence cost reduction from migration has been modelled accurately — accounting for the fact that Oracle licences and support fees are not eliminated until Oracle deployments are fully decommissioned and licences are formally terminated.
High
Expert note: Oracle licence cost savings from a PostgreSQL migration are only realised when Oracle is fully decommissioned. A parallel-run period — where both Oracle and PostgreSQL are live — generates double the infrastructure cost and no Oracle licence saving. Many migrations extend the parallel-run period far beyond original estimates, delaying the ROI realisation by 12–18 months. Build the migration timeline conservatively, and model the Oracle support cost separately from the PostgreSQL infrastructure cost to present an accurate total project ROI.
12
Your migration project timeline accounts for Oracle audit risk during the transition period — since Oracle audit activity increases when large customers begin reducing their Oracle dependency.
High
Expert note: Oracle's audit cadence correlates with customer behaviour. Organisations that publicly announce Oracle exit programmes, reduce Oracle support spend, or begin large migration projects frequently receive Oracle audit notifications within 12–24 months. Ensure your Oracle compliance position is thoroughly documented before the migration becomes visible to Oracle. Any compliance gap that is discovered during an audit triggered by a migration announcement becomes a negotiating obstacle in your Oracle exit — giving Oracle leverage to increase migration costs or delay licence termination.
13
You have identified all Oracle-based reporting, ETL, and analytics tools in scope — including Oracle Analytics Server, Oracle Reports, Oracle Forms, and OBIEE — and confirmed their migration or replacement strategy.
High
Expert note: Oracle databases often serve as the backend for Oracle-specific reporting and analytics tools that do not run on PostgreSQL. Oracle Analytics Server, OBIEE, Oracle Reports, and Oracle Forms are all Oracle-database-specific. If your migration scope includes databases that underlie these tools, the reporting layer must be replaced simultaneously or held in Oracle while reporting migration is planned. Failed Oracle-to-PostgreSQL migrations are often caused by an underestimated reporting tool replacement scope that adds months to the programme timeline.
14
You have modelled the total cost of migration — including tooling, professional services, parallel running, testing, application code changes, and training — against the Oracle licence and support cost saving to confirm a positive ROI within 36 months.
High
Expert note: Oracle-to-PostgreSQL migration projects frequently exceed budget and timeline estimates. A PoC-validated estimate for a 10TB Oracle estate with significant PL/SQL complexity typically ranges from £500k to £2 million in professional services and project costs, exclusive of internal effort. Compare this against the Oracle cost saving: if you save £500k per year in Oracle support, payback is 1–4 years. If the saving is £100k per year, the migration economics may be weak. Build the ROI model before the migration programme is approved — and update it after the PoC reveals actual conversion complexity.
15
Your migration governance includes an Oracle compliance checkpoint at project completion — confirming that all Oracle licences have been formally terminated, support has been cancelled with correct notice, and Oracle has acknowledged the termination in writing.
High
Expert note: Oracle licence costs continue until Oracle licences are formally terminated in writing, with proper notice under the Oracle licence agreement and MSL policy. A migration that decommissions Oracle databases but fails to formally terminate the licences continues to generate Oracle support invoices indefinitely. At project completion, conduct a formal Oracle licence termination process: identify the licences to be terminated, confirm MSL compliance, provide written termination notice to Oracle before the renewal date, and obtain Oracle's written acknowledgement that the licences and support have been terminated.
Section 4
Tooling, Target Environment, and Governance
16
You have evaluated AWS Database Migration Service (DMS), Oracle SCT, Ora2Pg, and other automated migration tools — and confirmed which tooling is most appropriate for your specific Oracle version, schema complexity, and PL/SQL volume.
Medium
Expert note: Migration tooling selection significantly affects project cost and timeline. Oracle SCT (Schema Conversion Tool) produces automated conversion reports with complexity scores and identifies manual conversion work. Ora2Pg is an open-source tool with strong EBS migration support. AWS DMS is well-suited for data replication during cutover but does not handle PL/SQL conversion. No single tool handles the full Oracle-to-PostgreSQL migration; most projects use a combination. Evaluate tooling output on a sample of your database schemas before committing to a tooling strategy for the full programme.
17
Your PostgreSQL target environment has been sized and provisioned — with storage, memory, CPU, and connection pooling — to match Oracle's performance characteristics for your workloads.
Medium
Expert note: PostgreSQL and Oracle have different performance profiles. Oracle's shared memory architecture and automatic query optimisation differ from PostgreSQL's process-based model. Write-heavy OLTP workloads, complex analytics queries, and large batch operations all behave differently between the two engines. Size the PostgreSQL environment at 130–150% of the Oracle resource specification for initial testing, and tune down based on observed performance during the PoC. Connection pooling via PgBouncer is typically required to replace Oracle's connection management for high-concurrency workloads.
18
Your migration risk register includes a rollback plan that allows return to Oracle in the event of a critical failure during or after cutover.
Medium
Expert note: Every Oracle-to-PostgreSQL migration cutover carries the risk of discovering critical issues that were not identified during testing. A rollback plan — with documented Oracle restore procedures, a defined rollback decision window (typically 48–72 hours post-cutover), and pre-tested revert procedures — is an operational necessity, not optional insurance. Design the rollback plan before cutover and test it in a non-production environment. A migration that cannot be reversed is an unacceptable operational risk for business-critical Oracle systems.
19
You have assessed the PostgreSQL skills gap in your organisation — including DBA expertise, developer familiarity with PL/pgSQL, and operational monitoring — and have a training and recruitment plan to close it.
Medium
Expert note: Oracle DBAs and PostgreSQL DBAs require different skills. Oracle's Enterprise Manager, AWR reports, and diagnostic tooling have PostgreSQL equivalents (pgAdmin, pg_stat_statements, Prometheus/Grafana for monitoring) but require specific training. PL/SQL developers need training on PL/pgSQL differences. Application developers accustomed to Oracle-specific SQL constructs need training on PostgreSQL's stricter type handling. Budget for skills development as an explicit project cost item — typically 10–15% of total migration programme cost for a first-time PostgreSQL adoption.
20
You have engaged independent Oracle licensing and database migration specialists — separate from Oracle, your incumbent systems integrator, and any cloud provider — to validate your migration feasibility assessment and Oracle exit strategy.
High
Expert note: Oracle has a commercial interest in preventing or delaying your migration. Your incumbent systems integrator may underestimate complexity to win the project. Cloud providers may overestimate benefits to accelerate migration to their managed PostgreSQL services. An independent specialist with both Oracle licensing expertise and database migration experience provides a neutral feasibility assessment: honest about complexity, honest about cost, and honest about Oracle's likely response. At Redress, we assess the full commercial and technical landscape before recommending a migration strategy — ensuring the Oracle exit is as valuable as the PostgreSQL adoption.
"Oracle-to-PostgreSQL migrations fail at the application layer, not the data layer. The schema conversion tools produce impressive-looking reports — but it's the 2 million lines of PL/SQL, the Oracle Forms, and the implicit type casting in your application code that determine whether the project succeeds or spends two years in rework." — Fredrik Filipsson, Redress Compliance
Interpreting Your Assessment Score
Count fully compliant items. Unknown answers should be treated as gaps for scoring purposes.
17–20
Strong Position
Controls mature. Schedule annual review to maintain as your estate evolves.
12–16
Moderate Exposure
Material gaps identified. Prioritise HIGH-risk items immediately and commission an independent review within 90 days.
0–11
High Exposure
Significant risk present. Do not engage Oracle commercially until independent specialists have assessed your position. Contact Redress immediately.
Oracle-to-PostgreSQL Migration in 2026: Opportunity and Reality
The commercial case for migrating from Oracle to PostgreSQL has never been stronger. Oracle Database Enterprise Edition at £25,000 per processor licence, combined with 22% annual support fees, generates a significant ongoing cost burden for any large Oracle estate. PostgreSQL is open-source, production-grade, and increasingly the default database platform for new applications across financial services, retail, and manufacturing. The technology risk is manageable — provided the migration is planned with honesty about PL/SQL conversion complexity, application code changes, and Oracle's audit response.
The most common reason Oracle-to-PostgreSQL migrations fail or deliver poor ROI is a combination of underestimated application code conversion, overestimated tooling automation, and an Oracle audit triggered by the migration activity that creates a compliance liability during a period of maximum project pressure. Plan the technical migration and the Oracle compliance exit as a single integrated programme — not as separate work streams with different accountable teams.
Redress Compliance provides independent Oracle licensing and exit strategy advice alongside technical migration assessment. We have no commercial relationship with Oracle, PostgreSQL vendors, or cloud providers. Our single objective is to help you exit Oracle as efficiently, compliantly, and profitably as possible.