01
Estate Assessment
Inventory of schemas, objects, sizes, features in use, database links, jobs and the applications that connect, classified low, medium or high effort per database.
Oracle to PostgreSQL Migration
Oracle to PostgreSQL Migration: Classify the Objects, Prove It on One Database, Then Move the Estate
Last reviewed by Tyler Eastridge
AceMQ plans and runs Oracle to PostgreSQL migrations with partner Oracle and PostgreSQL specialists: a classified inventory of every object, a proof of value on one database, a data-movement method chosen for your downtime budget, and a cutover with a rollback agreed in writing. Tables and indexes are the easy part. The work is PL/SQL, packages, jobs and links, so we measure that first and tell you which databases should stay on Oracle.
- Oracle 19c Premier Support ends, per Oracle
- Dec 2029
- PostgreSQL 18 final release date, per postgresql.org
- Nov 2030
- hour to a reply on a quote request
- 1
Is This You?
You probably need this if…
- 01
The case for leaving Oracle was made in a slide deck and nobody has classified which databases could actually move
- 02
A tool vendor promised automatic conversion, and the first run left a pile of PL/SQL marked for manual review
- 03
Business logic lives in packages, triggers and scheduler jobs, and the people who wrote them have left
- 04
The estate runs to dozens of databases with database links between them, so they cannot move one at a time without a plan
- 05
The application cannot be down for a weekend, so a dump-and-load is off the table
- 06
A change board wants a rollback story before it approves a cutover date
- 07
You have run a tool-only proof of concept and want an independent view of what it did and did not prove
Outcomes
Where you are now, and where you end up
Concrete state changes, not deliverable counts. This is what actually differs about your Oracle Database estate when the engagement closes.
Before
The estate is one line in a business case: "migrate Oracle to PostgreSQL".
After
Every database classified by how much Oracle-specific code it holds, with an effort class, an order of work and a plain list of the ones that should stay.
Before
A tool converts the schema and the team assumes the migration is mostly done.
After
A reviewed conversion where every unconverted object has an owner and a replacement design, tested against the application's own queries.
Before
The data move is a single weekend and everyone hopes it fits.
After
A method chosen on evidence: an offline load where downtime is acceptable, or a full load plus change capture where the old database must keep serving until cutover.
Before
Cutover has no way back.
After
A rehearsed cutover with a written rollback: what is kept as the fallback, what would be lost, and who decides at each checkpoint.
Scope
What's covered
- 02
Proof of Value
One representative database converted, loaded and tested end to end before anyone commits to a program, so the estimate rests on a result and not a tool demo.
- 03
Schema and Data Types
Tables, constraints, indexes, sequences and partitions mapped to PostgreSQL, with an explicit data type map decided before any data moves.
- 04
PL/SQL Conversion Review
Functions, procedures, packages and triggers converted with tooling, then reviewed and tested by engineers, because the tools themselves say the output must be reviewed.
- 05
Packages and Oracle Built-ins
Package structure moved to schemas, session state redesigned, and Oracle-specific functions mapped to PostgreSQL features or the orafce extension where that is the right choice.
- 06
Data Movement
Offline export and load, or full load plus change data capture, chosen against your downtime budget and rehearsed on production-sized data.
- 07
Validation
Row counts, checksums and application-level checks on both sides, before and after cutover.
- 08
High Availability and Backup Design
A PostgreSQL primary and standby design with backup and restore tests, sized to your recovery targets. High availability is a design deliverable, not a conversion output.
- 09
Handover and Run
Runbooks for your DBAs, and an optional move to 24/7 PostgreSQL support or managed service so patching and version upgrades have an owner.
The Engagement
How it actually runs
Every phase has a defined duration and a concrete artifact handed over at the end of it. You always know what stage you're in and what you've received.
- Phase 1Scoped per estate
Assess
Inventory and classify every database by Oracle-specific dependency. Run the assessment tooling, then read the output ourselves: tool scores are a starting point, not the estimate.
You receive
- Inventory of schemas, objects, features, links and jobs
- Effort class per database (low, medium, high)
- List of databases that should stay on Oracle, with reasons
- Phase 2Scoped per database
Prove on one database
Convert, load and test one representative database end to end, including its application queries and its jobs, and write down every object that needed manual work.
You receive
- Converted schema and code for one database
- Test results against the application
- Estimate for the rest of the estate based on that result
- Phase 3Scoped per program
Design
Target version and layout, conversion approach, data-movement method, high availability design, cutover order across databases that depend on each other, and the rollback for each.
You receive
- Target design and PostgreSQL version choice
- Data-movement and cutover plan
- Rollback plan and go or no-go checkpoints
- Phase 4Per database, in waves
Convert and rehearse
Convert, load and validate each database on a copy of production, timed, until the cutover fits the window. Nothing reaches production before it has been rehearsed.
You receive
- Reviewed conversion per database
- Measured load and cutover times
- Validation reports (counts, checksums, application checks)
- Phase 5Planned change window
Cut over and hand over
AceMQ and your team run the production cutover with the checkpoints agreed in design, then hand over runbooks and monitoring, with 24/7 support available afterwards.
You receive
- Validated PostgreSQL production
- Runbooks and monitoring
- Optional move to 24/7 support or managed service
What converts mechanically and what needs an engineer
The tools do real work on structure. They are open about the rest: Ora2Pg's documentation describes the PL/SQL conversion as basic and says generated functions, procedures, packages and triggers have to be reviewed. AWS's own migration playbook says not every Oracle feature is fully compatible or has a simple workaround. We classify objects by how they behave in that light.
| Oracle object | What the documentation says | What we do |
|---|---|---|
| Tables, indexes, constraints, sequences | Ora2Pg exports them. AWS SCT converts sequences and advises checking that new values do not overlap existing ones. The PostgreSQL porting guide maps varchar2 to varchar or text and number to numeric. | Mechanical, but the data type map is decided column by column from the data, before loading. |
| Partitioned tables | AWS SCT converts range, list, multicolumn range, hash and composite partitioning. | Check the partition keys and local-index assumptions against how queries use them. |
| ROWID | AWS SCT turns ROWID into a data column of type bigint or character varying. | Find code that depends on ROWID and decide per use whether a real key is needed. |
| Packages | PostgreSQL has no packages. The porting guide says to use schemas to group functions and to keep per-session state in temporary tables. | By hand. Package structure, initialization and shared state are redesigned, not translated. |
| Functions, procedures, triggers | Ora2Pg performs basic automatic conversion to PL/pgSQL; the output must be reviewed. | Convert with tooling, then review and test every routine against the application. |
| Exceptions and error handling | Exception names differ in PL/pgSQL, user-defined exception names cannot be declared, and dup_val_on_index becomes unique_violation. An EXCEPTION block rolls back changes since its BEGIN. | Rewrite error handling deliberately, and test the failure paths the application relies on. |
| Dynamic SQL | PL/pgSQL EXECUTE works similarly but needs quote_literal and quote_ident. AWS SCT converts EXECUTE IMMEDIATE and DBMS_SQL calls. | Review every dynamic statement for quoting and injection safety, whatever the tool produced. |
| DBMS_OUTPUT, UTL_FILE, DBMS_PIPE, DBMS_ALERT and similar | The orafce extension emulates a named subset. Its own documentation says DBMS_SQL compatibility is not full and that it brings no performance advantage over native PL/pgSQL. | Use orafce where it fits, as a bridge, and list every call that stays so nothing is forgotten. |
| Database links, synonyms, materialized views | Ora2Pg lists them among its export types, including database links and foreign data wrapper tables. | Each link is a cross-database dependency. It decides the order of cutover, not just a conversion line. |
| RAC and Data Guard | The PostgreSQL high availability chapter defines primary and standby servers, warm and hot standby, and synchronous and asynchronous replication. | Design the PostgreSQL topology from your recovery targets. It is a separate deliverable, not an equivalent of RAC. |
What we do not claim
We do not give a conversion percentage. No vendor page we read states one, and the figure depends on how much logic your databases hold in PL/SQL. The proof of value on one database produces your number.
Moving the data: offline load, or full load plus change capture
The data-movement choice comes from one question: how long can the application stop? Ora2Pg exports data as INSERT or COPY statements, and its own site labels that data migration offline and requires downtime. The same site points to a separate product, HexaRocket, for change capture, live replication and rollback, and says a migration may still need manual fixes, deeper validation or production cutover support. AWS DMS can run a one-time migration or replicate ongoing changes. pgloader loads into PostgreSQL from MySQL, SQL Server and other sources, but its site states that Oracle is not supported as a source.
| Method | Fits when | Cost of the choice |
|---|---|---|
| Offline export and load | The application can stop for the length of a rehearsed load, such as a maintenance window or a quiet period. | Downtime equals the measured load time, so load time on production-sized data is measured in rehearsal, not estimated. |
| Full load plus change data capture | The Oracle database must keep serving until cutover, or the load is too long for any window. | Source-side prerequisites such as logging, a lag to monitor, and a validation step that compares moving data. |
| Wave by wave across databases | Databases depend on each other through links, so they cannot all cut over at once. | A period when some databases are on PostgreSQL and some on Oracle, which the plan has to cover. |
Change capture is what lets the old database stay live until the day of cutover, and it keeps the fallback honest. The design states for each database what the rollback is: keep the Oracle source frozen as the fallback, or replicate back, and what writes made on PostgreSQL after cutover would be lost in each case.
Rule we hold
Never combine a platform migration with a version upgrade in one production window. Pick the PostgreSQL version in design, move onto it, and plan later major upgrades as their own change.
The dates on both sides of the move
Dates frame the decision but do not make it. Oracle's policy gives you time on 19c, and PostgreSQL's versioning policy tells you how long the target will be supported. A target with a longer runway means fewer forced upgrades after the move.
| Release | Vendor or community date | Note |
|---|---|---|
| Oracle Database 19c | Premier Support ends December 2029; Extended Support ends December 2032 | Oracle's policy excludes some Java 8 related software for 19c ports; check its footnote for your platform. |
| Oracle Database 21c | Premier Support ends July 2027; no Extended Support | An innovation release. |
| Oracle AI Database 26ai | Premier Support ends December 2031; Extended Support to be determined | The long term support release, generally available October 2025. |
| PostgreSQL 14 | Final release 12 November 2026 | Community support ends in November 2026; not a target for a new move. |
| PostgreSQL 15 | Final release 11 November 2027 | Short runway for a new target. |
| PostgreSQL 16 | Final release 9 November 2028 | Supported five years from its first release. |
| PostgreSQL 17 | Final release 8 November 2029 | First released 26 September 2024. |
| PostgreSQL 18 | Final release 14 November 2030 | First released 25 September 2025. |
AceMQ gives no advice on Oracle licensing or on what you owe under your agreement. The dates are Oracle's and PostgreSQL's own.
Who this is not for
- Teams expecting automated conversion with only licence costs — Business logic held in the database is usually the largest part of the work. If the plan assumes a tool does it all, the proof of value will say so early, and cheaply.
- Application rewrites — We convert the database and its procedural code. Changes to application code are made by your developers, and we tell them which queries and settings to change.
- Oracle applications — E-Business Suite, Fusion and similar applications built on Oracle are out of scope. Their databases stay on Oracle.
- Estates that depend on Oracle-only platforms — Deep use of RAC, Exadata, APEX or Forms may be cheaper to keep. We say so after the assessment, not before it.
- Anyone who needs licence negotiation — AceMQ is an independent provider: it does not resell Oracle licences, negotiate with Oracle or defend an audit.
Typical engagements
How these engagements run
Typical engagement scenarios: what the work covers and what it delivers. They describe the service, not past results.
Oracle to PostgreSQL Assessment and Proof of Value
Regional Insurer
A typical engagement for a team weighing an exit from Oracle: classify every object by conversion effort, then convert and test one representative database before committing to the rest.
PostgreSQLOracle DatabaseOra2PgAWS DMS
Debezium Oracle LogMiner Lag Remediation
Regional Retail Bank
Bringing an Oracle change data capture pipeline back inside its batch window after nightly jobs left the Debezium connector hours behind the source.
DebeziumOracle
Kafka
KubernetesDebezium MySQL Binlog Retention and Schema History Support
Online Travel Platform
Ongoing support for a MySQL change data capture pipeline that needed a full re-snapshot after a planned outage outlasted binlog retention and a trimmed schema history topic.
Debezium
MySQLSQL ServerOracle DatabaseKafka
Amazon RDS
Oracle Data Guard Failover Readiness Review
Regional Insurer
A typical engagement to find out whether an Oracle Data Guard standby will really take over: transport and apply lag, protection mode, redo sizing, failover runbooks and client reconnection.
Oracle DatabaseData GuardRMANLinuxOracle 19c to 26ai Upgrade Planning
Industrial Manufacturing Group
A typical engagement to decide whether Oracle databases should stay on 19c or move to 26ai, and to plan the multitenant conversion, AutoUpgrade run and rollback for the ones that move.
Oracle DatabaseAutoUpgradeMultitenantLinux
Remote Oracle DBA Cover for a Small Platform Team
SaaS Platform Team
A typical engagement where a lean platform team adds remote Oracle DBA cover: on-call, restore testing, patch windows and a monthly review, without hiring a second DBA.
Oracle DatabaseRMANPrometheusLinuxOracle to PostgreSQL Data Movement, Cutover Rehearsal and Rollback Design
SaaS Platform Team
A typical engagement for a team that has converted its Oracle schema and now has to move the data: choose offline load or change capture per database, rehearse on production-sized data, and write the rollback before a date is set.
Oracle DatabasePostgreSQLAWS DMSOra2Pg
FAQ
Questions about Oracle Database to PostgreSQL migration
Can AceMQ migrate our Oracle databases to PostgreSQL?
Yes, as a planned program delivered by AceMQ engineers with partner Oracle and PostgreSQL specialists. It starts with an assessment that classifies every database by Oracle-specific dependency, then a proof of value on one database, then waves of conversion, rehearsal and cutover. We give timelines and prices only after the assessment, because both depend on how much PL/SQL, how many links and how much data the estate holds.
Will a tool convert our PL/SQL automatically?
Partly. Ora2Pg's documentation describes its PL/SQL conversion as basic and says the generated functions, procedures, packages and triggers must be reviewed. AWS SCT puts action items into the output where it could not convert code. Engineers review and test every routine, and rebuild what the tools cannot convert, such as package state.
Can the application keep running during the move?
Often, with full load plus change data capture, which keeps the Oracle database serving until a short cutover. It needs source-side prerequisites and a validation step, and we rehearse it on production-sized data first. An offline load is simpler where a rehearsed maintenance window is acceptable. The design picks one per database.
What happens if the cutover goes wrong?
The design states the rollback for each database before any date is set: the Oracle source stays untouched as the fallback until sign-off, or changes are replicated back, and what would be lost in each case. The change board sees the go or no-go checkpoints in advance, and the rollback is rehearsed with the cutover.
Does the service include changing our application code?
No. We convert the database and its procedural code and tell your developers which queries, settings and drivers change. Application code stays with your team, or with another partner you choose.
Let's talk
Scope an Oracle to PostgreSQL Migration
Tell us how many Oracle databases you run, their sizes and releases, and how much downtime you can accept. We reply within 1 hour and follow with a written assessment plan.
Get in Touch
Talk to an Oracle Database Expert
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.com66 W. Flagler St. 9th Floor
Miami, FL 33130
Miami, FL 33130
Prefer to talk now? Call us directly or use the consultation tab to find a time that works.