Oracle to PostgreSQL Pre-Flight Checklist
A pre-flight checklist for Oracle-to-PostgreSQL migrations covering object inventory, data-type and NULL-semantic gaps, PL/SQL rewrite scope, and validation. It surfaces Oracle-specific risks early so planning and effort estimates are realistic. Use it before any build work begins.
When to Use This Checklist
Use this checklist before you begin an Oracle-to-PostgreSQL migration. Oracle and PostgreSQL share SQL roots but differ in data types, procedural languages, NULL handling, and proprietary features. A disciplined pre-flight pass surfaces the hard parts early, while you still have time to plan, rather than discovering them mid-migration.
How to Use This Checklist
Start with discovery: build a complete inventory of schema objects and the application SQL that touches them. Then move into planning, where each Oracle-specific construct gets a documented decision: keep, rewrite, or redesign. The required items represent risks that will break a migration if ignored; the optional items refine performance and operational fit. Capture every mapping decision in a migration design document so the build phase is mechanical, not exploratory.
What Good Looks Like
A strong pre-flight produces a complete object inventory, a data-type mapping table with no unresolved lossy conversions, and a list of every PL/SQL unit slated for rewrite to PL/pgSQL. NULL and empty-string semantics, sequence handling, and ROWNUM usage are all explicitly addressed. You have a chosen migration method sized to your data volume, a per-table validation plan, and a rollback strategy. The team can estimate effort with confidence because the surprises are already on the table.
Common Pitfalls
The classic trap is the empty-string-equals-NULL difference, which changes query results in subtle ways. Teams also underestimate PL/SQL rewrite effort and the behavioral gaps in hierarchical queries and analytic functions. Character-set conversion to UTF-8 can corrupt data if collation and encoding are not planned. Finally, performance assumptions rarely transfer: an index strategy tuned for Oracle's optimizer may behave differently under PostgreSQL, so benchmark before you commit.
Related Resources
Ground your schema work in schema-evolution-schema-registry thinking and design parity checks with data-quality-management. Use the expand-and-contract-migration-pattern to migrate incrementally, and frame the overall effort with the continuous-modernization-playbook.