The decision to migrate Oracle Forms to PostgreSQL and eliminate Oracle licensing costs starts with two converging pressures: a closing support window and a licensing structure that grows more expensive as infrastructure scales. Oracle Forms was designed for a different era of enterprise software — but the platform still runs mission-critical workloads in government, banking, insurance, and logistics today.
Oracle Forms 12c Premier Support is scheduled to end in late 2026 per Oracle’s Fusion Middleware Lifetime Support Policy. Extended Support runs through December 2027, covering security patches only, at an additional fee. After that comes Sustaining Support: no new security patches, error correction only on a per-incident basis. Oracle has extended Premier Support twice before — the original end date was December 2023, then December 2025, then the current date. Verify the current timeline at docs.oracle.com/en/middleware/fusion-middleware/endsupport.html before any project planning.
End-of-life pressure compounds a licensing structure that grows more expensive as infrastructure scales.
Oracle Database Enterprise Edition list price is approximately $47,500 per Processor license (Oracle Technology Price List, March 2025; verify current pricing at oracle.com before publication). Oracle’s published Premier Support rate is 22% of net license fee annually, with some enterprise agreements in the 22–25% range. For a mid-market deployment of 4 servers with 16 physical cores each — 64 cores total — the Intel x86 core factor of 0.5 yields 32 Oracle Processor licenses. At list price, that is $1,520,000 in license fees, plus $334,400 per year in support. Over five years at list: $3,192,000. With a typical 50% enterprise discount, the figure drops to roughly $1,596,000 — still a material outlay, before cloud infrastructure enters the picture.
The cloud penalty is significant. Running Oracle Database on AWS or Azure (not OCI) triggers a licensing asymmetry: Oracle maps 2 vCPUs to 1 Processor license on those platforms, per Oracle’s cloud licensing policy. That same 64-core workload on a 64-vCPU AWS instance requires 64 Oracle Processor licenses — double the bare-metal count. Every cloud migration that keeps Oracle Database in place compounds the exposure.
Oracle License Management Services (LMS) — also called Global Licensing and Advisory Services (GLAS) — conducts proactive audits. Organizations typically dedicate significant staff time to Oracle’s data collection requests, often measured in weeks. Non-compliance findings can result in multi-million-dollar retroactive license exposure. That risk belongs in the enterprise risk register, not just the IT budget.
Table 1: Oracle Database vs. PostgreSQL — Licensing and Cost Comparison
| Dimension | Oracle Database Enterprise Edition | PostgreSQL |
| License cost | ~$47,500/Processor license (list price, March 2025 Oracle Technology Price List; verify at publication) | $0 |
| Annual maintenance | 22% of net license fee (Oracle published rate; some agreements 22–25%) | $0 (community); optional paid support via EnterpriseDB, Crunchy Data, Percona |
| Cloud licensing penalty | 2:1 vCPU-to-Processor ratio on AWS/Azure (not OCI) | None |
| Audit risk | Oracle LMS/GLAS audits; retroactive license exposure | None |
| DBA talent pool | Specialist; shrinking | Broad; growing |
The phrase “migrate Oracle Forms to PostgreSQL” conflates two distinct migration efforts that require different teams, tools, and timelines. Understanding the split is the first step to scoping the project accurately.
Problem 1 — Oracle Database to PostgreSQL. Schema migration, data migration, PL/SQL-to-PL/pgSQL conversion. This layer is semi-automated. Ora2pg, AWS Schema Conversion Tool (SCT), and AWS Database Migration Service (DMS) collectively handle the routine work — tables, views, sequences, indexes, stored procedures — with varying degrees of automation and manual review for complex logic.
Problem 2 — Oracle Forms .fmb UI layer to modern web framework. The visual interface — canvases, blocks, items, and PL/SQL triggers embedded in the form module — has no automated migration path to React, Angular, or any other web framework. No automated tool converts Oracle Forms .fmb files to a modern web framework — that layer of the migration is predominantly manual effort. This is typically the larger effort of the two.
Oracle Forms is a rapid application development environment used to build data-entry-heavy enterprise applications directly against Oracle Database. Oracle Forms 12c — the current production version — runs on Oracle WebLogic Server. Form definitions are stored in proprietary binary .fmb files. Canvases, blocks, items, and PL/SQL triggers are all embedded in the .fmb binary. Oracle’s own Forms Migration Assistant converts Forms applications to Oracle ADF — an Oracle-to-Oracle path that does not eliminate Oracle dependency.
ora2pg is an open-source Perl command-line tool that connects to an Oracle database, reads the schema catalog, and generates PostgreSQL-compatible DDL and PL/pgSQL scripts. It handles tables, views, sequences, indexes, grants, partitions, triggers, stored procedures, and packages. It generates an assessment report scoring each object as Simple, Medium, or Complex. Ora2pg does not touch Oracle Forms .fmb files.
One important decision point: migrating Oracle Forms to Oracle APEX is faster and lower-risk than rebuilding in React or Angular — but APEX does not eliminate Oracle licensing. APEX requires Oracle Database. For organizations whose primary goal is to reduce Oracle licensing costs, APEX is a consolidation play, not an exit.
No single tool handles an Oracle-to-PostgreSQL migration end to end. The practical toolchain is a combination of instruments, each with a defined scope — and defined limits.
Ora2pg reads the Oracle schema catalog and generates PostgreSQL DDL and PL/pgSQL scripts. It converts tables, views, sequences, triggers, stored procedures, functions, packages (restructured into PostgreSQL schemas), partitions, and grants. Its assessment mode assigns a migration cost score — Simple, Medium, or Complex — to every object before conversion begins. Ora2pg does not convert complex PL/SQL business logic, Oracle-specific constructs (CONNECT BY, BULK COLLECT, FORALL, UTL_FILE, DBMS_* packages, PRAGMA AUTONOMOUS_TRANSACTION), or Oracle Forms .fmb UI code.
AWS Schema Conversion Tool (SCT) reads Oracle schema and PL/SQL, generates PostgreSQL DDL and PL/pgSQL, and produces a detailed assessment report. Its Action Items tab lists every object requiring manual resolution, categorized as Simple, Medium, or Complex. SCT handles schema conversion; AWS DMS handles data movement downstream. SCT does not convert .fmb files.
AWS Database Migration Service (DMS) is a fully managed AWS service for database migration and ongoing replication. Full Load mode performs a one-time bulk copy from Oracle to PostgreSQL. Full Load + Change Data Capture (CDC) mode runs the initial load and then continuously replicates all subsequent changes — keeping Oracle and PostgreSQL in sync during the parallel-run validation window. DMS does not perform schema conversion — SCT handles that upstream.
Pgloader performs bulk data loading using PostgreSQL’s COPY command, with transaction-level retry on rejected rows. Best suited for fast initial data loads or as a complement to a full toolchain. Pgloader does not handle ongoing CDC; combine it with Debezium or AWS DMS for parallel-run scenarios.
EnterpriseDB (EDB) Migration Portal offers Oracle-to-EDB Postgres Advanced Server (EPAS) assessment and schema conversion with AI Copilot assistance. EDB Postgres Advanced Server includes an Oracle-compatibility layer that can reduce PL/SQL rewrite scope. EPAS is a proprietary distribution — a viable intermediate step for organizations that need Oracle compatibility during a phased migration, not a permanent destination for those whose goal is license cost elimination.
Table 2: Oracle-to-PostgreSQL Migration Tool Comparison
| Tool | Schema Conversion | PL/SQL Conversion | Data Migration | CDC (Ongoing Sync) | Converts .fmb? |
| ora2pg | Yes (full) | Partial — simple logic only | Yes | No | No |
| AWS SCT | Yes (full) | Partial — simple logic only | No | No | No |
| AWS DMS | No (use SCT first) | No | Yes | Yes | No |
| pgloader | Partial | No | Yes (bulk only) | No | No |
| EDB Migration Portal | Yes | Yes (with AI Copilot assist) | No | No | No |
| Debezium | No | No | No | Yes (open-source) | No |
Before running ora2pg or AWS SCT, the team needs a full catalog of every Oracle-specific SQL construct in the codebase. Running conversion tools on untranslated Oracle SQL produces scripts that fail to compile or silently return incorrect results.
Oracle’s CONNECT BY hierarchical query syntax has no direct PostgreSQL equivalent and must be manually rewritten as a WITH RECURSIVE common table expression. This is the most consequential manual conversion in most Oracle codebases — it requires understanding the parent-child relationship and restructuring the recursion anchor and recursive member explicitly.
The table below is the conversion checklist your team needs before running ora2pg.
Table 3: Oracle SQL Constructs and Their PostgreSQL Equivalents
| Oracle Construct | PostgreSQL Equivalent | Notes |
| ROWNUM <= n | LIMIT n | Or ROW_NUMBER() OVER (ORDER BY col) <= n in a subquery for full equivalence |
| CONNECT BY PRIOR … START WITH | WITH RECURSIVE … AS (…) | Requires manual rewrite; not automated by ora2pg |
| NVL(a, b) | COALESCE(a, b) | Direct substitution; automated by most tools |
| DECODE(x, v1, r1, default) | CASE WHEN x=v1 THEN r1 ELSE default END | Automated by most tools |
| SYSDATE | LOCALTIMESTAMP or NOW() | LOCALTIMESTAMP has no timezone; NOW() includes timezone |
| SELECT 1 FROM DUAL | SELECT 1 | PostgreSQL allows SELECT without FROM |
| sequence_name.NEXTVAL | nextval(‘sequence_name’) | Syntax difference only; automated |
| ROWID | ctid | PostgreSQL ctid is unreliable across transactions; application logic must be redesigned |
| Oracle (+) outer join | LEFT JOIN / RIGHT JOIN | Standard ANSI syntax; automated by most tools |
| CREATE SYNONYM | PostgreSQL schemas + search_path | No direct DDL equivalent; schema reorganization required |
Sources: PostgreSQL wiki, EDB, AWS Aurora PostgreSQL Migration Playbook, Cybertec.
Ora2pg and AWS SCT handle the routine end of PL/SQL conversion: basic stored procedures and functions with standard SQL logic, simple cursor loops, common data type mappings (VARCHAR2 → VARCHAR, NUMBER → NUMERIC, DATE → TIMESTAMP), and straightforward constructs like NVL, DECODE, and Oracle outer join syntax.
Oracle PL/SQL packages have no direct PostgreSQL equivalent and must be restructured into PostgreSQL schemas, with package-level variables redesigned as session state. This is not a syntax problem — it is an architectural one. Package-level state in Oracle lives in the session as long as the package is loaded; PostgreSQL has no native equivalent. Each package must be decomposed, its state model redesigned, and its interdependencies mapped before conversion.
| Oracle PL/SQL Feature | PostgreSQL Approach |
| Packages | Restructure into PostgreSQL schemas; package-level variables require session-state redesign |
| PRAGMA AUTONOMOUS_TRANSACTION | Simulate via dblink extension — architecturally complex; evaluate whether the use case can be redesigned |
| BULK COLLECT | Rewrite using ARRAY_AGG, UNNEST, or standard cursor LOOP constructs |
| FORALL | No native equivalent; rewrite as individual DML statements or set-based SQL |
| UTL_FILE | Replace with pg_read_file() / PostgreSQL COPY command, or an external file-handling service |
| DBMS_OUTPUT | Replace with RAISE NOTICE for logging |
| DBMS_SCHEDULER / DBMS_JOBS | Replace with pg_cron extension or an external scheduler (Airflow, pgAgent) |
| DBMS_LOB | Replace with PostgreSQL lo_* functions or bytea type |
| Oracle exception names | Map to PostgreSQL SQLSTATE codes; custom exception hierarchies must be restructured |
| EXECUTE IMMEDIATE | PostgreSQL EXECUTE — similar behavior, but syntax differences require review |
Complex PL/SQL packages often encode years of accumulated business logic. The conversion process is an opportunity to document and simplify that logic — not only a cost. Teams that treat PL/SQL refactoring as a code audit frequently emerge with a cleaner, better-tested codebase than they had in Oracle.
After migration, PostgreSQL can run on self-managed servers or on a fully managed cloud service. Managed services abstract away patching, backups, Multi-AZ failover, and storage scaling — reducing DBA operational burden significantly.
Amazon Aurora PostgreSQL delivers 2–3x the throughput of standard Amazon RDS for PostgreSQL and typically fails over in under 30 seconds in Multi-AZ configurations. Aurora’s storage layer is distributed, self-healing, and replicated six ways across three Availability Zones.
Table 4: Cloud-Managed PostgreSQL Comparison
| Service | Provider | Key Highlight | Multi-AZ Failover | Pricing Model |
| Amazon RDS for PostgreSQL | AWS | Standard managed PostgreSQL; PITR, auto-patching, storage auto-scaling | Yes; typically < 60 sec | Compute + storage (no license fee) |
| Amazon Aurora PostgreSQL | AWS | PostgreSQL-compatible; 2–3x throughput of RDS; Aurora Global Database for cross-region | Yes; typically < 30 sec | Per-ACU (serverless) or provisioned |
| Azure Database for PostgreSQL | Microsoft Azure | Flexible Server and Hyperscale (Citus) options; tight Azure ecosystem integration | Yes | Compute + storage tiers |
| Google Cloud SQL for PostgreSQL | Google Cloud | Regional or multi-region HA; strong GKE integration | Yes | Compute + storage tiers |
The CIO’s primary objection to migration is downtime. The answer is a phased migration with a parallel run — Oracle stays authoritative throughout; PostgreSQL is validated before any traffic is redirected.
Change Data Capture (CDC) continuously captures row-level changes from a source database and replicates them to a target — enabling a parallel run in which Oracle remains authoritative while PostgreSQL is being validated. AWS DMS and Debezium are the two most common CDC tools for Oracle-to-PostgreSQL migrations.
The migration program has four phases:
Phase 1 — Audit and Assessment. Run ora2pg in assessment mode and AWS SCT to generate a full object inventory with complexity ratings. Catalog all Oracle-specific SQL constructs before any conversion begins. Map the .fmb files: count canvases, blocks, items, and triggers to scope the manual rebuild effort for the UI layer.
Phase 2 — Schema Migration. Convert the schema using ora2pg or AWS SCT. Resolve all Action Items flagged by SCT. Validate the generated DDL in a PostgreSQL staging environment. Do not migrate data yet.
Phase 3 — Data Migration and Parallel Run. Use AWS DMS Full Load + CDC to migrate data and maintain continuous replication. During the parallel run, Oracle remains the system of record. PostgreSQL receives all writes via CDC replication. Run validation assertions — row-count checksums, hash-based field comparisons, business-rule invariants — against both systems simultaneously.
Phase 4 — Cutover. When validation passes for a module, redirect application traffic to PostgreSQL for that module. Oracle remains authoritative for modules not yet cut over. Rollback is a traffic routing change — Oracle has not been decommissioned.
During the parallel run, Oracle remains the system of record while AWS DMS CDC continuously replicates changes to PostgreSQL — cutover becomes a traffic routing decision, not a data restoration event.
For organizations preferring open-source tooling end to end, Debezium (Kafka-based, open-source CDC) captures Oracle changes via LogMiner and replicates to PostgreSQL without an Oracle GoldenGate dependency. Oracle GoldenGate delivers the highest CDC performance for Oracle-as-source but requires its own Oracle license — not appropriate for a migration program whose goal is to exit Oracle licensing.
Rollback triggers to define before cutover begins: data divergence between Oracle and PostgreSQL, performance regression under production load, integration failures with downstream systems. Oracle stays authoritative until all three pass.
The illustrative calculation for a mid-sized enterprise makes the financial argument concrete. Four servers, 16 physical cores each, 64 cores total. Intel x86 core factor of 0.5 = 32 Oracle Processor licenses. At Oracle Technology Price List pricing (March 2025), 32 licenses at list = $1,520,000 in license fees. Annual Premier Support at 22%: $334,400. Over five years at list: $3,192,000. With a 50% negotiated discount — common in enterprise agreements — approximately $1,596,000 over five years. The cloud scenario adds further: that same 64-core workload on AWS maps to 64 Oracle Processor licenses per Oracle’s cloud licensing policy, doubling the bare-metal exposure.
Exiting Oracle Database eliminates Oracle License Management Services audit exposure permanently — a risk reduction that does not appear in standard licensing cost comparisons.
Organizations that have migrated from Oracle to PostgreSQL report significant TCO reductions in licensing, support, and infrastructure costs — vendor-cited figures from EDB, Data Patrol Tech, and Newt Global; individual results vary by deployment scale and negotiated Oracle discounts. The migration cost is bounded and one-time. Oracle licensing, maintenance, and audit risk are ongoing and compound annually.
Hidden Oracle costs that disappear after migration:
Executing a large-scale platform migration under real production load requires a different kind of engineering than building greenfield systems. Pretius demonstrated that capability migrating the e-commerce backend of TVN’s Player.pl — a Warner Bros. Discovery VOD platform — to Amazon Web Services.
Pretius migrated TVN’s Player.pl e-commerce backend to AWS, enabling the VOD platform to serve over 60 million views in a single month. The platform’s AWS infrastructure auto-scaled to absorb traffic spikes that had previously created outage risk on fixed on-premise capacity. The migration demonstrated what cloud-native architecture delivers at media scale: elastic capacity, reduced infrastructure maintenance cost, and availability under event-driven load.
Read the full case study here.
Migration cost depends primarily on PL/SQL complexity and the size of the Oracle Forms UI layer. Schema migration and data migration tooling (ora2pg, AWS DMS) are engineering-labor costs for configuration and review. The largest cost drivers are PL/SQL refactoring for complex packages and the Forms UI rebuild — both scale linearly with application complexity. Organizations typically evaluate migration cost against the 3–5 year Oracle licensing outlay they are displacing to determine break-even.
PostgreSQL is ACID-compliant and handles enterprise OLTP workloads at scale across insurance, banking, government, and logistics verticals. Organizations including Apple, Instagram, and Shopify run PostgreSQL at billions-of-rows scale. For horizontal scaling, Citus (distributed PostgreSQL) and Patroni/pgBouncer architectures provide the HA and connection pooling that enterprise applications require. PostgreSQL does not have a native equivalent to Oracle Real Application Clusters (RAC) — that is the main architecture gap for extreme-scale OLTP.
No automated tool converts .fmb files to a modern web framework. The .fmb layer — canvases, blocks, items, PL/SQL triggers — must be rebuilt in the target web stack (typically React or Angular combined with a REST API layer). This rebuild is typically the largest single effort in an Oracle Forms migration program.
A phased approach — Audit, Schema Migration, Data Migration plus Parallel Run, Cutover — allows Oracle to remain the system of record throughout the entire migration program. Cutover happens module by module after parallel-run validation passes. Typical mid-market Oracle Forms exit programs run 6–18 months for a full migration.
CONNECT BY (hierarchical queries) and BULK COLLECT/FORALL (bulk operations) require complete manual rewrites — no tool automates them. ROWNUM, NVL, DECODE, and SYSDATE have direct PostgreSQL equivalents that most tools handle automatically. Oracle packages are the largest structural challenge: they must be decomposed into PostgreSQL schemas with careful handling of package-level state.
Aurora PostgreSQL is compatible at the wire protocol level — standard PostgreSQL drivers, tools, and extensions work without modification. The underlying storage layer is Aurora-proprietary (distributed, self-healing, six-way replicated across three Availability Zones). Applications written for standard PostgreSQL run on Aurora without code changes.
Yes. Oracle licenses must remain active while Oracle is still running as the system of record. During the parallel-run phase, both Oracle and PostgreSQL are live simultaneously. Budget for continued Oracle license costs through the cutover date for each module. Oracle decommissioning is the final step after all modules have been validated in production on PostgreSQL.
Pretius has executed large-scale cloud migrations for enterprise clients at media scale — including TVN’s Player.pl VOD platform, a Warner Bros. Discovery property, which serves over 60 million views per month on the AWS infrastructure Pretius built and migrated to. For organizations evaluating an Oracle exit strategy, Pretius applies the same migration rigor — combined with their Oracle Forms modernization practice — to deliver Oracle-to-open-source migrations.
If you are ready to scope your Oracle Forms migration, start with the case study or schedule a consultation using the contact form below.
