The Challenge
The client operated a distributed Oracle Database Enterprise Edition estate across six manufacturing sites in three European countries, plus a central ERP and analytics hub. The estate had grown organically — databases provisioned by individual site teams, each licensed on Processor metric using Oracle's Core Factor Table across a mix of Intel Xeon and AMD EPYC hardware. Oracle Enterprise Support was running at 22% of net licence value annually, compounding on an estate that the client acknowledged was over-licensed relative to actual workload requirements.
The IT Director's primary concern was not the migration itself — the engineering team had PostgreSQL experience from a greenfield project — but the Oracle licence implications. Migrating Oracle Database workloads to PostgreSQL does not automatically reduce Oracle licence costs unless the migration is structured correctly. Oracle's Processor licences are perpetual and remain on the licence schedule indefinitely unless the client formally removes products from Oracle support. Simply moving workloads to another database while leaving Oracle EE licences on the support schedule achieves nothing commercially — Oracle continues to invoice 22% annual support on licences the client no longer uses.
Additionally, the client had three databases running Oracle-specific features — Oracle Advanced Security, Oracle Partitioning, and Oracle Real Application Clusters — that were not straightforward to replicate in PostgreSQL without architectural changes. Migrating these databases without understanding the feature dependencies risked either a failed migration or a discovery that the PostgreSQL replacement required significant additional development investment. The client needed an independent assessment of the Oracle licensing commercial position, a feature dependency analysis for each database, and a structured migration sequence that would deliver commercial savings in a predictable timeline.
Our Approach
- Step 1 — Oracle Licence Position Analysis: We conducted a full Oracle Database licence inventory across all six sites and the central hub. Using the client's USMM data and our own verification of the Core Factor Table calculations across each server, we established the current Oracle Processor licence entitlement and the associated annual support liability. We identified three categories of licensing inefficiency: eight databases running on servers with a Core Factor of 1.0 where the physical licence count matched workload requirements; fourteen databases running on high-core-count EPYC processors where the Core Factor of 0.25 meant the client held significant excess licence capacity relative to actual database utilisation; and four databases where the client was inadvertently running Database Options (Diagnostics Pack and Advanced Security) that were not covered by their current licence schedule, creating an undisclosed compliance gap of approximately $620K.
- Step 2 — Workload and Feature Dependency Assessment: For each of the 36 Oracle Database instances in scope (four of the 40 were Oracle E-Business Suite databases excluded from migration scope), we conducted a workload characterisation and Oracle-specific feature dependency scan using DBA_FEATURE_USAGE_STATISTICS. The output classified each database against four migration profiles: (a) Migrate-ready — standard SQL workloads, no Oracle-specific features in active use, minimal schema complexity; (b) Migrate-with-refactoring — Oracle-specific PL/SQL packages, sequences, or Data Guard dependencies requiring code changes; (c) Migrate-complex — Oracle-specific features in active use including RAC, Partitioning, or Advanced Security where PostgreSQL equivalents required architectural decisions; (d) Retain — databases with deep Oracle application integration (Oracle Forms, Oracle Reports, Oracle Streams) where migration was technically viable but the development cost exceeded the five-year licence saving.
- Step 3 — Commercial Case Modelling: For each database, we built a five-year total cost of ownership model comparing Oracle licence retention against PostgreSQL migration. The model incorporated the Oracle Processor licence cost for that workload, annual support at 22%, PostgreSQL infrastructure and operations costs, and estimated migration effort in development days. For the 28 databases in the Migrate-ready and Migrate-with-refactoring categories, the PostgreSQL TCO was materially lower in every case — the payback period ranged from 8 to 18 months depending on migration complexity. For the eight databases in the Migrate-complex and Retain categories, the five-year Oracle TCO was lower than or comparable to migration when development costs were included honestly.
- Step 4 — Oracle Licence Reduction Planning: This was the commercially critical step that most organisations miss. Migrating to PostgreSQL produces Oracle licence savings only if Oracle licences are formally reduced. We structured the licence reduction in coordination with the client's Oracle CSI account: removing the 28 migrated databases' Processor licences from the Oracle Support schedule in tranches as each migration was completed, eliminating the compliance gap on the four databases running unlicensed Options, and right-sizing the remaining eight Oracle EE instances against their actual server configurations using the Core Factor Table — reducing the retained Oracle estate by a further 12 Processor licences without any migration required.
- Step 5 — Migration Execution Support: We provided Oracle licensing oversight for the 14-month migration programme — advising the engineering team on Oracle-specific schema conversion issues, validating that each decommissioned Oracle database was formally removed from the Oracle support schedule before the next quarterly billing cycle, and providing a compliance sign-off at programme completion confirming the residual Oracle estate matched the client's licence schedule. The programme completed four weeks ahead of schedule. Oracle issued a revised support invoice reflecting the reduced estate on Month 16 of the programme.
Oracle Database Migration: Feature Dependency Classification
The classification of each Oracle Database instance was the commercial foundation of the programme. The table below shows the aggregate distribution across the 36 databases assessed:
| Classification | Database Count | Oracle Features Active | Migration Decision |
|---|---|---|---|
| Migrate-ready | 16 | None | MIGRATE |
| Migrate-with-refactoring | 12 | PL/SQL packages, sequences | MIGRATE |
| Migrate-complex | 5 | RAC, Partitioning, Advanced Security | RETAIN |
| Retain (Oracle app integration) | 3 | Oracle Forms, Streams | RETAIN |
The Results
Key Takeaways
- Oracle-to-PostgreSQL migration requires licence reduction planning, not just technical migration — moving workloads without removing Oracle licences from the Support schedule produces zero commercial benefit
- Feature dependency analysis using DBA_FEATURE_USAGE_STATISTICS is the most reliable method for classifying Oracle databases against migration viability — Oracle's own tooling provides the evidence
- The Core Factor Table creates licence optimisation opportunities independent of migration — right-sizing Oracle EE on EPYC processors reduced the retained estate by 12 Processor licences without any database changes
- Oracle Database Options (Diagnostics Pack, Advanced Security, Partitioning) are accidentally active in the majority of enterprise estates — proactive compliance review before migration prevents audit exposure during the transition
- Not all Oracle databases should migrate — honest TCO modelling for complex Oracle-specific workloads often favours retention, and acting on that analysis protects programme credibility
- Independent Oracle licence optimisation delivers savings both on databases that migrate and on those that remain
"We knew we wanted to migrate but we didn't know what we could migrate without creating a bigger problem than the one we were solving. The independent analysis gave us a clear picture of what to move and what to leave — and then made sure we actually captured the licence savings when we did move. Without that second part, we'd have spent 18 months on engineering work and seen no change on our Oracle invoice."— IT Director, European Automotive Manufacturer
Oracle Database Licensing After Migration
The most common failure mode in Oracle-to-open-source migration programmes is the disconnect between the engineering team, which celebrates a successful PostgreSQL deployment, and the procurement team, which receives an unchanged Oracle support invoice the following quarter. Oracle's Perpetual licences do not expire — and Oracle's Support billing continues on every licence in the CSI schedule until the client formally submits a licence removal request and Oracle processes it. The billing lag between migration completion and Oracle support reduction is typically one to two quarters, meaning organisations that do not manage the Oracle licence schedule as part of their migration programme absorb months of unnecessary Oracle support costs after the technical work is complete.
Our Oracle License Optimisation practice manages the full commercial lifecycle of Oracle-to-open-source migrations — from pre-migration licence analysis through to post-migration support invoice validation. We also work with organisations evaluating the migration decision at feasibility stage, providing honest commercial modelling before engineering investment is committed. See our Oracle Database Licensing Guide for a full breakdown of Processor and Named User Plus metric mechanics, and our Oracle to PostgreSQL Migration Analysis white paper for the commercial framework used in this engagement.