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 license 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 license implications. Migrating Oracle Database workloads to PostgreSQL does not automatically reduce Oracle license costs unless the migration is structured correctly. Oracle's Processor licenses are perpetual and remain on the license schedule indefinitely unless the client formally removes products from Oracle support. Simply moving workloads to another database while leaving Oracle EE licenses on the support schedule achieves nothing commercially — Oracle continues to invoice 22% annual support on licenses 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 License Position Analysis: We conducted a full Oracle Database license 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 license 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 license 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 license capacity relative to actual database utilization; and four databases where the client was inadvertently running Database Options (Diagnostics Pack and Advanced Security) that were not covered by their current license 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 license saving.
- Step 3 — Commercial Case Modelling: For each database, we built a five-year total cost of ownership model comparing Oracle license retention against PostgreSQL migration. The model incorporated the Oracle Processor license 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 License Reduction Planning: This was the commercially critical step that most organizations miss. Migrating to PostgreSQL produces Oracle license savings only if Oracle licenses are formally reduced. We structured the license reduction in coordination with the client's Oracle CSI account: removing the 28 migrated databases' Processor licenses 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 licenses without any migration required.
- Step 5 — Migration Execution Support: We provided Oracle licensing oversight for the 14-month migration program — 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 program completion confirming the residual Oracle estate matched the client's license schedule. The program completed four weeks ahead of schedule. Oracle issued a revised support invoice reflecting the reduced estate on Month 16 of the program.
Oracle Database Migration: Feature Dependency Classification
The classification of each Oracle Database instance was the commercial foundation of the program. 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 license reduction planning, not just technical migration — moving workloads without removing Oracle licenses 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 license optimization opportunities independent of migration — right-sizing Oracle EE on EPYC processors reduced the retained estate by 12 Processor licenses 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 program credibility
- Independent Oracle license optimization 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 license 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 programs 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 licenses do not expire — and Oracle's Support billing continues on every license in the CSI schedule until the client formally submits a license removal request and Oracle processes it. The billing lag between migration completion and Oracle support reduction is typically one to two quarters, meaning organizations that do not manage the Oracle license schedule as part of their migration program absorb months of unnecessary Oracle support costs after the technical work is complete.
Our Oracle License Optimization practice manages the full commercial lifecycle of Oracle-to-open-source migrations — from pre-migration license analysis through to post-migration support invoice validation. We also work with organizations 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.