PluginBench
Skill
Official
Pass
Audit score 90

creating-oracle-to-postgres-master-migration-plan

github/awesome-copilot

Discover .NET projects, classify Oracle dependencies, and generate a structured migration plan for PostgreSQL conversion.

What is creating-oracle-to-postgres-master-migration-plan?

Analyzes a .NET solution to identify all projects, classifies each for Oracle-to-PostgreSQL migration eligibility, and produces a persistent master migration plan document. Use this when starting a multi-project Oracle-to-PostgreSQL migration, creating a migration inventory, or assessing which projects contain Oracle dependencies.

  • Discovers all projects in a .NET solution by parsing .sln/.slnx files
  • Scans projects for Oracle indicators: NuGet packages, config entries, and code usage patterns
  • Classifies each project as MIGRATE, SKIP, ALREADY_MIGRATED, or TEST_PROJECT
  • Generates a structured MasterMigrationPlan.md with project inventory and recommended migration order
  • Presents classifications to user for review and adjustment before finalizing

How to install creating-oracle-to-postgres-master-migration-plan

npx skills add https://github.com/github/awesome-copilot --skill creating-oracle-to-postgres-master-migration-plan
Prerequisites
  • A .NET solution file (.sln or .slnx) in the workspace root
  • Access to project files (.csproj, packages.config, appsettings.json, web.config, app.config)
Claude Code
Cursor
Windsurf
Cline

How to use creating-oracle-to-postgres-master-migration-plan

  1. 1.Locate or confirm the solution file (.sln/.slnx) in the workspace root
  2. 2.The skill will discover and parse all project references from the solution file
  3. 3.Review the classified project list presented by the skill (MIGRATE, SKIP, ALREADY_MIGRATED, TEST_PROJECT)
  4. 4.Adjust classifications or migration ordering as needed based on your knowledge of dependencies
  5. 5.Confirm to finalize; the skill writes MasterMigrationPlan.md to .github/oracle-to-postgres-migration/Reports/

Use cases

Good for
  • Starting a large multi-project Oracle-to-PostgreSQL migration and need a roadmap
  • Creating a migration inventory to track which .NET projects depend on Oracle
  • Assessing migration scope and dependencies across a solution before beginning conversion work
  • Planning the order of project migrations to handle shared libraries before dependents
Who it's for
  • Database migration engineers
  • DevOps and infrastructure teams planning Oracle-to-PostgreSQL transitions
  • .NET solution architects managing multi-project migrations
  • Teams using GitHub Copilot for migration automation

creating-oracle-to-postgres-master-migration-plan FAQ

What indicators does the skill use to detect Oracle dependencies?

It scans for NuGet packages (Oracle.ManagedDataAccess, Oracle.EntityFrameworkCore), Oracle connection strings in config files, code patterns like OracleConnection/OracleCommand, and DDL artifacts in the .github/oracle-to-postgres-migration/DDL/Oracle/ directory.

Can I adjust the classification of a project before the plan is written?

Yes. After the skill presents the classified list, you can review and modify classifications or migration order before confirming to write the final plan.

Where is the master migration plan saved?

The plan is saved to .github/oracle-to-postgres-migration/Reports/MasterMigrationPlan.md and follows a standard structure that downstream agents and skills can parse.

How does the skill order projects for migration?

Projects are ordered so that shared and foundational libraries (especially data access layers) are migrated before projects that depend on them.

What happens to test projects?

Test projects are classified separately as TEST_PROJECT and are handled by a dedicated testing workflow rather than the main migration process.

Full instructions (SKILL.md)

Source of truth, from github/awesome-copilot.


name: creating-oracle-to-postgres-master-migration-plan description: 'Discovers all projects in a .NET solution, classifies each for Oracle-to-PostgreSQL migration eligibility, and produces a persistent master migration plan. Use when starting a multi-project Oracle-to-PostgreSQL migration, creating a migration inventory, or assessing which .NET projects contain Oracle dependencies.'

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:

ClassificationMeaning
MIGRATEHas Oracle interactions requiring conversion
SKIPNo Oracle indicators (UI-only, shared utility, etc.)
ALREADY_MIGRATEDA -postgres or .Postgres duplicate exists and appears processed
TEST_PROJECTTest 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/MasterMigrationPlan.md

Use this exact template — downstream consumers depend on the structure:

# Master Migration Plan

**Solution:** {solution file name}
**Solution Root:** {REPOSITORY_ROOT}
**Created:** {timestamp}
**Last Updated:** {timestamp}

## DDL Artifacts

**Location:** {path to DDL artifacts, e.g., `.github/oracle-to-postgres-migration/DDL/`}
**External tool used:** {Yes / No} — {If Yes, name the tool (e.g., `ora2pg`) and note that Phase 4 (Schema & DDL Migration) can be skipped; PostgreSQL DDL artifacts already exist.}

## 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.