Creating Oracle To Postgres Master Migration Plan
Inventory every project in a .NET solution and produce a parseable Oracle-to-PostgreSQL master migration plan before touching code.
Overview
Creating Oracle-to-PostgreSQL Master Migration Plan is an agent skill most often used in Build (also Operate) that discovers .NET solution projects, classifies Oracle dependencies, and writes a persistent master migratio
Install
npx skills add https://github.com/github/awesome-copilot --skill creating-oracle-to-postgres-master-migration-planWhat is this skill?
- Four-step workflow: discover solution projects, classify Oracle eligibility, confirm with the user, write the persistent
- Scans .csproj and packages.config for Oracle.ManagedDataAccess and Oracle.EntityFrameworkCore
- Flags Oracle connection strings in appsettings.json, web.config, and app.config
- Detects OracleConnection, OracleCommand, and OracleDataReader usage in non-test projects
- Structured output intended for downstream migration agents and skills to parse
- 4-step workflow from discovery through writing the plan file
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 have a large .NET solution and no ordered, file-backed map of which projects actually touch Oracle before you commit to PostgreSQL.
Who is it for?
Maintainers kicking off a coordinated Oracle-to-PostgreSQL move across multiple class libraries, APIs, and consoles in one solution.
Skip if: Single-script greenfield Postgres apps with no Oracle references or teams that already have an approved migration inventory locked.
When should I use this skill?
Starting a multi-project Oracle-to-PostgreSQL migration, creating a migration inventory, or assessing which .NET projects contain Oracle dependencies.
What do I get? / Deliverables
You get a confirmed, structured master migration plan every downstream migration step can reference instead of re-scanning the repo from scratch.
- Persistent master migration plan file
- Per-project Oracle eligibility classification
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Database migration planning is the canonical first shelf in Build because it happens before refactors and package swaps on backend projects. Backend subphase fits solution-wide Oracle dependency scanning, connection strings, and NuGet/classification work rather than UI or launch tasks.
Where it fits
Classify each API and library for Oracle NuGet and connection string usage before ordering refactors.
Re-run classification after production config drift to see which services still point at Oracle.
Use the plan to sequence cutover-ready projects versus blocked ones before a launch window.
How it compares
Use this inventory-and-classification workflow instead of ad-hoc grep sessions that never land in a shared plan file.
Common Questions / FAQ
Who is creating-oracle-to-postgres-master-migration-plan for?
Solo builders and indie teams on .NET solutions who must know which projects contain Oracle before planning PostgreSQL swaps.
When should I use creating-oracle-to-postgres-master-migration-plan?
At the start of a multi-project Oracle-to-PostgreSQL effort in Build, and again in Operate when reassessing scope after dependency changes.
Is creating-oracle-to-postgres-master-migration-plan safe to install?
Review the Security Audits panel on this Prism page and treat any plan that lists connection strings or secrets as sensitive before committing it to git.
SKILL.md
READMESKILL.md - Creating Oracle To Postgres Master Migration Plan
# Creating an Oracle-to-PostgreSQL Master Migration Plan Analyze a .NET solution, classify every project for Oracle→PostgreSQL migration eligibility, and write a structured plan that downstream agents and skills can parse. ## Workflow ``` Progress: - [ ] Step 1: Discover projects in the solution - [ ] Step 2: Classify each project - [ ] Step 3: Confirm with user - [ ] Step 4: Write the plan file ``` **Step 1: Discover projects** Find the Solution File (it has a `.sln` or `.slnx` extension) in the workspace root (ask the user if multiple exist). Parse it to extract all `.csproj` project references. For each project, note the name, path, and type (class library, web API, console, test, etc.). **Step 2: Classify each project** Scan every non-test project for Oracle indicators: - NuGet references: `Oracle.ManagedDataAccess`, `Oracle.EntityFrameworkCore` (check `.csproj` and `packages.config`) - Config entries: Oracle connection strings in `appsettings.json`, `web.config`, `app.config` - Code usage: `OracleConnection`, `OracleCommand`, `OracleDataReader` - DDL cross-references under `.github/oracle-to-postgres-migration/DDL/Oracle/` (if present) Assign one classification per project: | Classification | Meaning | |---|---| | **MIGRATE** | Has Oracle interactions requiring conversion | | **SKIP** | No Oracle indicators (UI-only, shared utility, etc.) | | **ALREADY_MIGRATED** | A `-postgres` or `.Postgres` duplicate exists and appears processed | | **TEST_PROJECT** | Test project; handled by the testing workflow | **Step 3: Confirm with user** Present the classified list. Let the user adjust classifications or migration ordering before finalizing. **Step 4: Write the plan file** Save to: `.github/oracle-to-postgres-migration/Reports/Master Migration Plan.md` Use this exact template — downstream consumers depend on the structure: ````markdown # Master Migration Plan **Solution:** {solution file name} **Solution Root:** {REPOSITORY_ROOT} **Created:** {timestamp} **Last Updated:** {timestamp} ## Solution Summary | Metric | Count | |--------|-------| | Total projects in solution | {n} | | Projects requiring migration | {n} | | Projects already migrated | {n} | | Projects skipped (no Oracle usage) | {n} | | Test projects (handled separately) | {n} | ## Project Inventory | # | Project Name | Path | Classification | Notes | |---|---|---|---|---| | 1 | {name} | {relative path} | MIGRATE | {notes} | | 2 | {name} | {relative path} | SKIP | No Oracle dependencies | ## Migration Order 1. **{ProjectName}** — {rationale, e.g., "Core data access library; other projects depend on it."} 2. **{ProjectName}** — {rationale} ```` Order projects so that shared/foundational libraries are migrated before their dependents.