Get off Oracle without breaking the application that pays the bills.

For straight CRUD procedures and simple functions, ora2pg gets 70-85% of the syntax right. For anything involving packages, autonomous transactions, %ROWTYPE chains, or Oracle-specific built-ins like DBMS_OUTPUT and UTL_FILE, the output compiles but behaves differently or doesn't compile at all. We treat ora2pg's PL/SQL output as a first draft. Every package over a few hundred lines gets a human rewrite with unit tests against captured Oracle inputs and outputs.

AWS SCT is the better choice when you're already committed to RDS or Aurora Postgres and want the conversion report tightly integrated with DMS for the data movement phase. It also handles application code scanning for embedded SQL, which ora2pg doesn't. ora2pg wins on schema and PL/SQL fidelity and on running anywhere. We commonly use SCT for the assessment and DMS handoff, and ora2pg for the actual schema and procedural conversion.

Oracle sequences map to Postgres sequences, but the semantics differ. Oracle's CACHE with NOORDER can produce non-monotonic IDs across RAC nodes; Postgres sequences are monotonic per session. If your application depends on ID ordering for anything, audit it. We convert most sequence-backed columns to GENERATED BY DEFAULT AS IDENTITY, which is cleaner to dump and restore. After every data load you must reset the sequence to MAX(id)+1 or first inserts will collide.

Rewrite them as recursive CTEs using WITH RECURSIVE. The translation is mechanical but the performance profile changes. Oracle's CONNECT BY has decades of optimization; Postgres recursive CTEs materialize at each step. For deep hierarchies, expect to add indexes on the parent_id column and possibly a path-based denormalization (ltree or a materialized closure table) for read-heavy workloads. We benchmark these specifically before cutover because they're a frequent regression point.

For a database running Oracle Enterprise Edition with options like Partitioning, Advanced Security, or Diagnostics Pack, customers typically eliminate 60-80% of database licensing spend after migration. The remaining cost shifts to Postgres infrastructure (RDS, Aurora, or self-managed) and ongoing engineering. Standard Edition migrations show smaller savings. The ROI also depends on whether you can decommission Oracle entirely or need to run both during a transition — running both for a year erases most year-one savings.

Yes, for most OLTP systems. We use AWS DMS or Oracle GoldenGate to replicate changes from Oracle to Postgres in near-real-time while you validate. Application traffic stays on Oracle until you're ready to flip. The actual cutover is a brief read-only window — typically 5-30 minutes — to drain in-flight transactions and confirm replication lag is zero. Reporting workloads and data warehouses often tolerate longer windows and don't need DMS.

It matters if you're a federal agency or a prime contractor with small business or SDVOSB set-aside requirements. We're certified through SBA's VetCert program and can be awarded directly under SDVOSB sole-source authority up to the applicable thresholds, or compete on set-aside vehicles. For commercial customers it's irrelevant to the technical work — same engineers, same approach. The certification just opens contracting paths that other firms can't access.

Real Application Clusters, Flashback, and Data Guard don't have one-to-one replacements. RAC's shared-storage active-active model maps to Postgres patterns like Patroni with streaming replication plus a connection pooler — different architecture, similar availability outcomes. Flashback queries can be approximated with temporal tables or a CDC stream into a separate audit store. We document each gap during assessment with the proposed Postgres pattern and the operational tradeoff, so nothing surprises you at cutover.

A mid-size OLTP system — say 500GB of data, 30-50 packages, a few hundred tables — runs 8-12 weeks from kickoff to cutover when the team is focused. Larger systems with heavy PL/SQL or strict compliance review can run 6-9 months. The data copy is rarely the bottleneck. The bottleneck is application regression testing, query plan tuning, and the operational runbooks for the new platform. We sequence work so you see a running Postgres replica within the first 2-3 weeks.