Questions that matter before an Oracle to PostgreSQL migration.
Focused on code, dependencies, target platform and evidence—not just object counts.
What should be examined first in an Oracle to PostgreSQL migration?
Not just tables and data types. Packages, procedures, functions, triggers, dynamic SQL, database links, Scheduler jobs, Oracle-specific features and application callers are usually more important.
Is PostgreSQL or Aurora automatically the right target?
No. The target has to fit application behaviour, availability, operating model, extensions and migration path. Critical properties should be validated with representative code and realistic load.
Why are object counts a poor effort estimate?
Two systems with the same number of tables can have completely different migration effort. A small package with session state, dynamic SQL and many callers can be harder than hundreds of simple tables.
What happens to PL/SQL packages?
First identify the package’s role: data logic, API, state, batch processing or business rules. Then decide what remains as PostgreSQL functions, what is rewritten, and what should move out of the database.
What role can automated conversion tools play?
Tools such as Ora2Pg can help with inventory, export and conversion. They do not replace the decision about how Oracle-specific logic, dependencies, testing and operations should behave on the target.
Do source code or customer data need to be sent to external AI services?
No. My internal analysis tools are designed for local project work. The data used in an engagement is agreed to fit the customer environment and scope.
What do you need for an initial enquiry?
Oracle version, approximate scale, relevant schemas, PL/SQL footprint, target platform and the main unresolved question. That is enough for a first assessment.
Have a specific question about your Oracle system?
Send the main open point together with the Oracle version and intended target.