Reviewing Oracle To Postgres Migration
Surface Oracle versus PostgreSQL behavioral risks before migration and verify translated artifacts and tests afterward.
Overview
Reviewing Oracle to Postgres migration is an agent skill most often used in Validate (also Build backend, Ship testing) that flags Oracle/PostgreSQL behavioral risks and validates migration coverage.
Install
npx skills add https://github.com/github/awesome-copilot --skill reviewing-oracle-to-postgres-migrationWhat is this skill?
- Two modes: risk assessment while planning migrations and validation after migration work completes
- Risk assessment workflow: identify scope, screen reference insights for applicability, document risks and actions
- Covers empty strings, REF CURSOR, type coercion, sorting, timestamps, and concurrent transaction differences
- Cross-references bundled references/ insights against procedures, triggers, queries, views, and calling application code
- Validation mode confirms every applicable insight was addressed and integration tests reflect PostgreSQL semantics
- 3-step risk assessment workflow: scope, screen insights, document risks
- Two task types: planning (risk assessment) and validating completed migration work
Adoption & trust: 1.6k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are migrating off Oracle but do not know which semantic differences will break procedures, cursors, or app code—and whether tests prove Postgres behavior.
Who is it for?
Teams with paired migration artifacts who need a structured checklist before translating PL/SQL and a second pass before release.
Skip if: Net-new Postgres apps with no Oracle lineage, or teams seeking automatic DDL translation without human review.
When should I use this skill?
Planning a database migration, reviewing migration artifacts, or validating that integration tests cover Oracle/PostgreSQL differences.
What do I get? / Deliverables
You get a scoped risk list with recommended actions before migration, then a validation pass confirming insights and integration tests match PostgreSQL semantics—invoke procedure migration only after planning risks are d
- Risk assessment with applicable insights and recommended actions
- Validation report tying migrated artifacts to covered behavioral differences
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Planning mode fits Validate when you scope migration work; validation mode extends into Ship testing—Validate is the first gate. Scoping which procedures, triggers, and client refcursor code are in scope matches validate/scope before heavy Build translation.
Where it fits
List affected procedures and app refcursor callers, then screen reference insights before any PL/pgSQL rewrite.
Pre-flight a single Oracle package migration to see which sorting and timestamp rules apply.
After migration PR merges, verify each applicable insight has a test asserting PostgreSQL behavior.
Re-run validation when promoting a migrated schema to a staging cutover environment.
How it compares
Migration risk and test-coverage checker—not a code generator; pair with procedural translation skills for the write path.
Common Questions / FAQ
Who is reviewing-oracle-to-postgres-migration for?
Solo builders and backend leads planning an Oracle exit who need insight-driven risk lists and post-migration validation against known behavioral deltas.
When should I use reviewing-oracle-to-postgres-migration?
In Validate when scoping a migration object and screening references; in Build before translating a procedure; in Ship when validating that integration tests cover empty-string, cursor, and timestamp semantics.
Is reviewing-oracle-to-postgres-migration safe to install?
It analyzes repository migration files and references read-only patterns; review the Security Audits panel on this page and avoid pointing it at production credentials in prompts.
Workflow Chain
Then invoke: migrating oracle to postgres stored procedures
SKILL.md
READMESKILL.md - Reviewing Oracle To Postgres Migration
# Oracle-to-PostgreSQL Database Migration Surfaces migration risks and validates migration work against known Oracle/PostgreSQL behavioral differences documented in the `references/` folder. ## When to use 1. **Planning** — Before starting migration work on a procedure, trigger, query, or refcursor client. Identify which reference insights apply so risks are addressed up front. 2. **Validating** — After migration work is done, confirm every applicable insight was addressed and integration tests cover the new PostgreSQL semantics. ## Workflow Determine the task type: **Planning a migration?** Follow the risk assessment workflow. **Validating completed work?** Follow the validation workflow. ### Risk assessment workflow (planning) ``` Risk Assessment: - [ ] Step 1: Identify the migration scope - [ ] Step 2: Screen each insight for applicability - [ ] Step 3: Document risks and recommended actions ``` **Step 1: Identify the migration scope** List the affected database objects (procedures, triggers, queries, views) and the application code that calls them. **Step 2: Screen each insight for applicability** Review the reference index in [references/REFERENCE.md](references/REFERENCE.md). For each entry, determine whether the migration scope contains patterns affected by that insight. Read the full reference file only when the insight is potentially relevant. **Step 3: Document risks and recommended actions** For each applicable insight, note the specific risk and the recommended fix pattern from the reference file. Flag any insight that requires a design decision (e.g., whether to preserve Oracle empty-string-as-NULL semantics or adopt PostgreSQL behavior). ### Validation workflow (post-migration) ``` Validation: - [ ] Step 1: Map the migration artifact - [ ] Step 2: Cross-check applicable insights - [ ] Step 3: Verify integration test coverage - [ ] Step 4: Gate the result ``` **Step 1: Map the migration artifact** Identify the migrated object and summarize the change set. **Step 2: Cross-check applicable insights** For each reference in [references/REFERENCE.md](references/REFERENCE.md), confirm the behavior or test requirement is acknowledged and addressed in the migration work. **Step 3: Verify integration test coverage** Confirm tests exercise both the happy path and the failure scenarios highlighted in applicable insights (exceptions, sorting, refcursor consumption, concurrent transactions, timestamps, etc.). **Step 4: Gate the result** Return a checklist asserting each applicable insight was addressed, migration scripts run, and integration tests pass. # Reference Index | File | Brief description | | --- | --- | | [empty-strings-handling.md](empty-strings-handling.md) | Oracle treats '' as NULL; PostgreSQL keeps empty strings distinct—patterns to align behavior in code, tests, and migrations. | | [no-data-found-exceptions.md](no-data-found-exceptions.md) | Oracle SELECT INTO raises "no data found"; PostgreSQL doesn’t—add explicit NOT FOUND handling to mirror Oracle behavior. | | [oracle-parentheses-from-clause.md](oracle-parentheses-from-clause.md) | Oracle allows `FROM(TABLE_NAME)` syntax; PostgreSQL requires `FROM TABLE_NAME`—remove unnecessary parentheses around table names. | | [oracle-to-postgres-sorting.md](oracle-to-postgres-sorting.md) | How to preserve Oracle-like ordering in PostgreSQL using COLLATE "C" and DISTINCT wrapper patterns. | | [oracle-to-postgres-to-char-numeric.md](oracle-to-postgres-to-char-numeric.md) | Oracle allows TO_CHAR(numeric) without format; PostgreSQL re